SCP falla sin error

He experimentado un comportamiento muy extraño de SCP durante algún tiempo: cada vez que intento copiar un archivo, la salida de SCP contiene un montón de guiones bajos y el archivo no se copia.

$ scp test.txt 192.168.0.2:~
[email protected]'s password: 
 ________________________________________

Cuando creo una conexión SSH con Midnight Commander y copio archivos, funciona.

Alguna información sobre mi máquina:

$ ssh -V
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010

$ uname -a
Linux squatpc 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux

Y estoy ejecutando Kubuntu 11.04.

Editar: algo más de información según lo solicitado por los comentarios:

$ scp -v test.txt 192.168.0.2:~
Executing: program /usr/bin/ssh host 192.168.0.2, user (unspecified), command scp -v -t -- ~
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.0.2 [192.168.0.2] port 22.
debug1: Connection established.
debug1: identity file /home/job/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/job/.ssh/id_rsa-cert type -1
debug1: identity file /home/job/.ssh/id_dsa type -1
debug1: identity file /home/job/.ssh/id_dsa-cert type -1
debug1: identity file /home/job/.ssh/id_ecdsa type -1
debug1: identity file /home/job/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 28:f3:2b:31:36:43:9b:07:d8:33:ca:43:4f:ca:6c:4c
debug1: Host '192.168.0.2' is known and matches the ECDSA host key.
debug1: Found key in /home/job/.ssh/known_hosts:20
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/job/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/job/.ssh/id_dsa
debug1: Trying private key: /home/job/.ssh/id_ecdsa
debug1: Next authentication method: password
[email protected]'s password: 
debug1: Authentication succeeded (password).
Authenticated to 192.168.0.2 ([192.168.0.2]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -t -- ~
 ________________________________________
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 2120, received 1872 bytes, in 0.3 seconds
Bytes per second: sent 7783.1, received 6872.6
debug1: Exit status 0

$ type scp
scp is hashed (/usr/bin/scp)

scp Trabajo
fuente

Intente con -v para obtener información de depuración durante la copia.

EightBitTony

Además, por si acaso ... ¿Cuál es la salida de type scp?

rozcietrzewiacz

@EightBitTony: mira mis ediciones.

Trabajo

@rozcietrzewiacz: vea mis ediciones también :-)

Trabajo

Si lo hace ssh 192.168.0.2 echo hello, ¿obtiene alguna salida que no sea hello?

Gilles 'SO- deja de ser malvado'

Respuestas:

Ok LOL, acabo de descubrir cuál es el problema.

Como me gustan tanto las vacas, he puesto fortune | cowsayen la parte superior de mi .bashrcarchivo que produce resultados como los siguientes al comenzar bash:

 _______________________________________
< You will lose an important disk file. >
 ---------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Todo esto está bien (y a veces es divertido) cuando se ejecuta de forma bashinteractiva. Sin embargo, bash lee ~/.bashrccuando es interactivo y no un shell de inicio de sesión, o cuando es un shell de inicio de sesión y su proceso padre es rshdosshd . Cuando ejecuta scp, el servidor inicia un shell que inicia una scpinstancia remota . La salida de .bashrcconfunde scpporque se envía de la misma manera que se envían los scpdatos del protocolo. Aparentemente, se trata de un error conocido. Consulte aquí para obtener más detalles.

También tenga en cuenta que los guiones bajos que mencioné en la pregunta son los de la línea superior del globo de texto.

Entonces, la solución fue simple: puse lo siguiente en la parte superior de .bashrcla máquina remota (destino):

# If not running interactively, don't do anything
[[ $- == *i* ]] || return

Esta línea está presente de forma predeterminada, .bashrcpero se eliminó debido a mis muchas ediciones (aparentemente descuidadas).

Trabajo
fuente

echo "don't have a cow" | cowsay

Stéphane Gimenez

Wow, después de meses de scp que acaba de romperse, finalmente iluminaste la respuesta para mí. Nunca hubiera pensado en esto. Simplemente hice una mv ~/.bashrc ~/.bashrc.bakprueba y me aseguré de que ese fuera el problema, y funcionó después de hacerlo.

Jondlm

@ScottStensland Esto debe ir en la parte superior del control remoto .bashrc. El local es irrelevante. Tenga en cuenta que hubo un error tipográfico en mi comentario (la respuesta es correcta): es *i*, no *-*.

Gilles 'SO- deja de ser malvado'

NO NO NO. rtfm. bashrc se ejecuta para shells no interactivos. Si desea mensajes de vaca feliz cuando inicie sesión, cambie su bash_profile. Si desea tener sabiduría sobre las vacas cada vez que abre una X-Window, intente averiguar si este es uno de los MUCHOS escenarios en los que no debería escribir el terminal - unix.stackexchange.com/questions/9605/…

symcbean

AFAIK, la forma correcta de habilitar sin impedimentos scpes menos sobre qué condicional para stdout en su ~/.bashrcscript, y más sobre simplemente restringir la salida de pantalla al ~/.bash_profilescript. Al menos así es como funciona para mi distribución (CentOS).

Editar para mayor claridad:

Ponga solo líneas en su archivo ~ / .bashrc como lo requieren "todas" las conexiones remotas (es decir, establecer ciertos valores ENV está bien, pero no es posible hacer eco de texto legible para humanos).
YMMV

Mark Hudson
fuente

mente exponiendo? es decir, ¿cómo restringir la salida de pantalla al perfil .bash?

javadba

Por screensalida, quiero decir echo "Greetings, Master"o cualquier otra cosa que muestre la salida a la ventana de terminal. No ponga eso en su ~ / .bashrc - manténgalo en su script ~ / .bash_profile.

Mark Hudson