SCP falha sem erro

45

Estou com um comportamento muito estranho do SCP há algum tempo: sempre que tento copiar um arquivo, a saída do SCP contém um monte de sublinhados e o arquivo não é copiado.

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

Quando crio uma conexão SSH usando o Midnight Commander e copio os arquivos, ele funciona.

Algumas informações sobre minha 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

E eu estou executando o Kubuntu 11.04.

Edit: Mais algumas informações, conforme solicitado pelos comentários:

$ 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

e

$ type scp
scp is hashed (/usr/bin/scp)
Trabalho
fonte
1
Tente com -v para obter algumas informações de depuração durante a cópia.
EightBitTony
Além disso, apenas no caso de ... Qual é a saída type scp?
rozcietrzewiacz
@EightBitTony: veja minhas edições.
Job
@rozcietrzewiacz: veja minhas edições também :-)
Job
2
Se o fizer ssh 192.168.0.2 echo hello, você obtém outra saída além de hello?
Gilles 'SO- stop be evil'

Respostas:

77

Ok, LOL, acabei de descobrir qual é o problema.

Como gosto muito de vacas, coloquei fortune | cowsayno topo do meu .bashrcarquivo que produz uma saída como a seguinte ao iniciar bash:

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

Tudo bem (e às vezes engraçado) ao executar bashinterativamente. No entanto, o bash lê ~/.bashrcquando é interativo e não como um shell de logon, ou quando é um shell de logon e seu processo pai é rshdorsshd . Quando você executa scp, o servidor inicia um shell que inicia uma scpinstância remota . A saída de .bashrcconfunde scpporque é enviada da mesma maneira que os scpdados do protocolo são enviados. Aparentemente, este é um bug conhecido, veja aqui para mais detalhes.

Observe também que os sublinhados que mencionei na pergunta são aqueles na linha superior do balão de texto.

Portanto, a solução foi simples: coloquei o seguinte na parte superior da .bashrcmáquina remota (de destino):

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

Essa linha está presente no padrão, .bashrcmas foi descartada por causa das minhas muitas edições (aparentemente descuidadas).

Trabalho
fonte
echo "don't have a cow" | cowsay
Stéphane Gimenez
Uau, depois de meses de scp sendo quebrados, você finalmente iluminou a resposta para mim. Eu nunca teria pensado nisso. Eu apenas fiz um mv ~/.bashrc ~/.bashrc.bakteste e verifique se esse era o problema, e funcionou depois que eu fiz isso.
precisa saber é o seguinte
@ScottStensland Isso precisa ir no topo do controle remoto .bashrc. O local é irrelevante. Note-se que houve um erro de digitação no meu comentário (a resposta está correta): é *i*, não *-*.
Gilles 'SO- stop be evil' '
NÃO NÃO NÃO. rtfm. O bashrc é executado para shells não interativos. Se você quiser mensagens felizes de vaca quando fizer login, altere seu bash_profile. Se você deseja sabedoria da vaca toda vez que abrir uma janela X, tente descobrir se esse é um dos MUITOS cenários nos quais você não deve escrever o terminal - unix.stackexchange.com/questions/9605/…
symcbean
5

AFAIK, a maneira correta de ativar sem impedimentos scpé menos sobre qual condicional para stdout em seu ~/.bashrcscript e mais sobre simplesmente restringir a saída da tela para o ~/.bash_profilescript. Pelo menos é assim que funciona para minha distribuição (CentOS.)

Edite para maior clareza:

  1. Coloque apenas linhas no seu arquivo ~ / .bashrc, conforme exigido por "todas" conexões remotas (ou seja, definir certos vars ENV está OK, mas eco de texto legível por humanos não.)
  2. YMMV
Mark Hudson
fonte
mente expondo? ou seja, como restringir a saída da tela ao perfil .bash?
Javadba
1
Por screensaída, quero dizer, echo "Greetings, Master"ou qualquer outra coisa que exiba saída para a janela do terminal. Não coloque isso em seu ~ / .bashrc - mantenha-o em seu script ~ / .bash_profile.
Mark Hudson