scp "Verbindung verloren", aber ssh funktioniert gut

Ein Server, den ich in Ordnung bringen kann, hat begonnen, sich zu weigern, scp.

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

Mit scp -v -vkann ich sehen, dass die Verbindung erfolgreich ist und die Übertragung erfolgreich zu sein scheint, aber auf der anderen Seite wird keine Datei angezeigt.

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

Es ist eine CentOS 5.9-Maschine.

Dinge, die ich überprüft habe ...

Ich habe die Erlaubnis, in dieses Verzeichnis zu schreiben.
Der Benutzer hat eine sinnvolle Shell (/ bin / bash).
Ich habe versucht, mich ~/.ssh/configaus dem Weg zu räumen.
Das Scp'ing auf diese Maschine von anderen mit völlig anderen Betriebssystemen schlägt ebenfalls fehl.
Die Festplatte ist nicht voll.
Sshd neu starten.

/ var / log / Secure enthält ...

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

Was könnte ich als nächstes überprüfen?

ssh scp

— Schwern
quelle

Nicht der Fehler, den ich erwarten würde, aber nur für den Fall, machen Sie Ihr ~/.bashrcoder ~/.profileoder /etc/bash.bashrcoder /etc/profiledrucken Sie etwas zu STDOUT? bugzilla.redhat.com/show_bug.cgi?id=20527 . Und ich nehme an, Sie verwenden Linux?

— Terdon

Nee. Ich bekomme nur das Übliche Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4.

— Schwern

Gibt es irgendetwas in einem der Systemprotokolle auf dem Zielhost?

— Flup

@Flup Sieht normal aus. Ich habe gepostet, was in den Protokollen angezeigt wird, wenn ich eine Verbindung herstelle.

— Schwern

Könnten Sie strace -f -o /tmp/sshd.strace -p [pid of sshd]auf dem Server starten , es erneut versuchen und dann etwas aus dieser Datei veröffentlichen, das relevant aussieht?

— Flup

Hatte das gleiche Problem.

Wenn Sie eine minimale Installation von Centos durchgeführt haben, werden nur die Pakete opensshund installiert openssh-server, nicht jedoch die openssh-clients. sudo yum install openssh-clientswird Ihr Problem beheben.

— qux
quelle

Ich habe keinen Zugriff mehr auf diese Maschine, aber das scheint eine wahrscheinliche Antwort zu sein.

— Schwern

scpstellt eine sshVerbindung zum Remote-Host her und startet dann eine weitere Kopie des scpProgramms auf diesem Host. Die beiden scp-Instanzen kommunizieren über die ssh-Verbindung, um die Dateiübertragung durchzuführen.

"Verbindungsverlust" wird vom lokalen scpProgramm gedruckt , wenn die SSH-Verbindung vorzeitig unterbrochen wird. Der übliche Grund dafür ist, dass das scpProgramm auf dem Remote-Host entweder nicht gestartet werden konnte oder vorzeitig beendet wurde. Dies könnte geschehen sein, weil das scp-Programm nicht auf dem Remote-Host vorhanden ist oder nicht in Ihrem Befehl PATH enthalten ist oder nicht als ausführbar markiert ist oder nach dem Start abgestürzt ist oder etwas in dieser Richtung.

— Kenster
quelle

Wir hatten dieses Problem kürzlich auf einem unserer Systeme.

Wir konnten angemessen auf den Host-Server ssh, stellten jedoch fest, dass wir nicht vom Server zurück auf den Computer ssh konnten. Dies ist ein guter Ort, um Nachforschungen anzustellen. Wenn Sie dies nicht tun können, können Sie SCP nicht verwenden.

In unserem Fall hatte irgendwie (vielleicht eine verpfuschte Installation) unsere ssh-Binärdateien durch leere 0-Byte-Dateien ersetzt. Wann immer "ssh" ausgeführt wurde, passierte nichts.

Durch die Neuinstallation von openssh-clients haben wir die Binärdateien korrigiert und scp hat begonnen zu arbeiten.

yum reinstall openssh-clients

— Ultimation
quelle