scp "connessione persa" ma ssh funziona bene

10

Un server su cui posso scrivere bene ha iniziato a rifiutare di scp.

$ scp ~/tmp/foo user@some.example.com:~/tmp/
lost connection

Con scp -v -vposso vedere la connessione ha esito positivo e il trasferimento sembra riuscire, ma nessun file appare dall'altra parte.

OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/schwern/.ssh/config
debug1: /Users/schwern/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to testcurrent01.dev.liquidweb.com [10.30.152.254] port 22.
debug1: Connection established.
debug1: identity file /Users/schwern/.ssh/id_rsa type -1
debug1: identity file /Users/schwern/.ssh/id_rsa-cert type -1
debug1: identity file /Users/schwern/.ssh/id_dsa type -1
debug1: identity file /Users/schwern/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
...lots of authentication details...
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to user@some.example.com ([1.2.3.4]:22).
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: scp -v -t -- ~/tmp/
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 4576, received 2520 bytes, in 0.0 seconds
Bytes per second: sent 167737.0, received 92372.6
debug1: Exit status 0
debug1: compress outgoing: raw data 135, compressed 121, factor 0.90
debug1: compress incoming: raw data 66, compressed 52, factor 0.79
lost connection

È una macchina CentOS 5.9.

Cose che ho controllato ...

Ho il permesso di scrivere in quella directory.
L'utente ha una shell sensibile (/ bin / bash).
Ho provato a togliermi ~/.ssh/configdi mezzo.
scappare su quella macchina da altri con sistemi operativi completamente diversi fallisce.
Il disco non è pieno.
Riavvio di sshd.

/ var / log / secure contiene ...

Apr  4 14:23:22 some sshd[12576]: Postponed publickey for user from 1.2.3.4 port 33581 ssh2
Apr  4 14:23:22 some sshd[12575]: Accepted publickey for user from 1.2.3.4 port 33581 ssh2
Apr  4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session opened for user user by (uid=0)
Apr  4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session closed for user user

Cosa potrei controllare dopo?

ssh scp

— Schwern
fonte

2

Non è l'errore che mi aspetterei, ma nel caso, fai il tuo ~/.bashrco ~/.profileo /etc/bash.bashrco /etc/profilestampa qualcosa su STDOUT? bugzilla.redhat.com/show_bug.cgi?id=20527 . E presumo che tu stia usando Linux?

— terdon,

No. Ho appena preso il solito Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4.

— Schwern,

Qualcosa in uno dei registri di sistema sull'host di destinazione?

— Flup,

@Flup Sembra normale. Ho pubblicato ciò che appare nei registri quando mi collego.

— Schwern,

Potresti iniziare strace -f -o /tmp/sshd.strace -p [pid of sshd]sul server, riprovare, quindi pubblicare qualcosa di quel file che sembra rilevante?

— Flup,

1

Aveva lo stesso problema.

Se hai fatto un'installazione minima di Centos, installa solo i pacchetti opensshe openssh-serverma non i openssh-clients. sudo yum install openssh-clientsrisolverà il tuo problema.

— qux
fonte

Non ho più accesso a quella macchina, ma sembra una risposta probabile.

— Schwern,

4

scpfunziona effettuando una sshconnessione all'host remoto, quindi avviando un'altra copia del scpprogramma su quell'host. Le due istanze di scp comunicano tramite la connessione ssh per eseguire il trasferimento di file.

"connessione persa" viene stampata dal scpprogramma locale quando la connessione ssh si interrompe prematuramente. La solita ragione è che il scpprogramma sull'host remoto non è stato avviato o è uscito prematuramente. Questo potrebbe essere accaduto perché il programma scp non esiste sull'host remoto, o non è nel tuo comando PATH, o non è contrassegnato come eseguibile, o si è arrestato in modo anomalo dopo l'avvio o qualcosa del genere.

— Kenster
fonte

0

Di recente abbiamo riscontrato questo problema su uno dei nostri sistemi.

Abbiamo potuto ssh in modo appropriato sul server host, ma abbiamo scoperto che non potevamo ssh dal server sulla macchina. Questo è un buon posto per indagare, se non puoi farlo, non sarai in grado di usare SCP.

Nel nostro caso, in qualche modo (forse un'installazione pasticciata) avevano sostituito i nostri file binari ssh con file vuoti a 0 byte. Ogni volta che "ssh" veniva eseguito, non accadeva nulla.

Con la reinstallazione di openssh-client, abbiamo corretto i file binari e scp ha iniziato a funzionare.

yum reinstall openssh-clients

— Ultimation
fonte