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:~
job@192.168.0.2'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
job@192.168.0.2'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 no-more-sessions@openssh.com
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

y

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

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).

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:

1. 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).
2. YMMV