SCP fallisce senza errori


45

Ho sperimentato un comportamento molto strano di SCP da qualche tempo: ogni volta che provo a copiare un file, l'output di SCP contiene una serie di caratteri di sottolineatura e il file non viene copiato.

$ scp test.txt 192.168.0.2:~
job@192.168.0.2's password: 
 ________________________________________

Quando creo una connessione SSH usando Midnight Commander e copio i file, funziona.

Alcune informazioni sulla mia macchina:

$ 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 sto eseguendo Kubuntu 11.04.

Modifica: alcune informazioni aggiuntive come richiesto dai commenti:

$ 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

e

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

1
Prova con -v per ottenere alcune informazioni di debug durante la copia.
EightBitTony,

Inoltre, nel caso in cui ... Qual è l'output di type scp?
rozcietrzewiacz,

@EightBitTony: vedi le mie modifiche.
Giobbe

@rozcietrzewiacz: vedi anche le mie modifiche :-)
Lavoro il

2
Se lo fai ssh 192.168.0.2 echo hello, si ottiene alcun output diverso hello?
Gilles 'SO- smetti di essere malvagio' il

Risposte:


77

Ok LOL, ho appena capito qual è il problema.

Dal momento che come le mucche così tanto, ho messo fortune | cowsayin cima alla mia .bashrclima che produce un output simile a quanto segue quando si inizia bash:

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

Va tutto bene (e talvolta è divertente) quando si esegue in modo bashinterattivo. Tuttavia, bash legge ~/.bashrcquando è interattivo e non una shell di accesso, o quando è una shell di accesso e il suo processo padre è rshdosshd . Quando si esegue scp, il server avvia una shell che avvia scpun'istanza remota . L'output di .bashrcconfonde scpperché viene inviato nello stesso modo in cui vengono inviati i scpdati del protocollo. Questo è apparentemente un bug noto, vedi qui per maggiori dettagli.

Si noti inoltre che i caratteri di sottolineatura che ho citato nella domanda sono quelli nella riga superiore del fumetto.

Quindi la soluzione era semplice: ho messo quanto segue nella parte superiore della .bashrcmacchina remota (destinazione):

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

Questa riga è presente nel valore predefinito .bashrcma è stata eliminata a causa delle mie numerose modifiche (apparentemente trascurate).


echo "don't have a cow" | cowsay
Stéphane Gimenez,

Wow, dopo mesi di rottura di SCP, hai finalmente illuminato la risposta per me. Non ci avrei mai pensato. Ho appena fatto un mv ~/.bashrc ~/.bashrc.baktest per assicurarmi che quello fosse il problema, e ha funzionato dopo averlo fatto.
Jondlm,

@ScottStensland Questo deve andare nella parte superiore del telecomando .bashrc. Quello locale è irrilevante. Nota che c'era un refuso nel mio commento (la risposta è corretta): non lo *i*è *-*.
Gilles 'SO- smetti di essere malvagio' il

NO NO NO. RTFM. bashrc viene eseguito per shell non interattive. Se vuoi messaggi di mucca felici quando effettui l'accesso, modifica il tuo bash_profile. Se vuoi la saggezza delle mucche ogni volta che apri una X-Window, prova a capire se questo è uno dei MOLTI scenari in cui non dovresti scrivere il terminale - unix.stackexchange.com/questions/9605/…
symcbean

5

AFAIK, il modo giusto per abilitare senza ostacoli scpè meno su quale condizionale per stdout nello ~/.bashrcscript e più semplicemente sulla limitazione dell'output dello schermo allo ~/.bash_profilescript. Almeno è così che funziona per la mia distribuzione (CentOS.)

Modifica per chiarezza:

  1. Inserisci solo le righe nel tuo file ~ / .bashrc come richiesto da "tutte" le connessioni remote (vale a dire che l'impostazione di alcuni parametri ENV è OK, ma l'eco del testo leggibile dall'uomo non lo è.)
  2. YMMV

esporre la mente? cioè come limitare l'output dello schermo al profilo .bash?
Javavba,

1
Per screenoutput, intendo echo "Greetings, Master"o qualsiasi altra cosa che visualizza l'output nella finestra del terminale. Non inserirlo nel tuo ~ / .bashrc - tienilo nello script ~ / .bash_profile.
Mark Hudson,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.