scp „stracił połączenie”, ale ssh działa dobrze

10

Serwer, który mogę ssh w porządku, zaczął odmawiać scp.

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

Z scp -v -vwidzę połączenie się powiedzie, a transfer wydaje się uda, ale z drugiej strony pojawia się żaden plik.

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

Jest to maszyna CentOS 5.9.

Rzeczy, które sprawdziłem ...

Mam uprawnienia do zapisu w tym katalogu.
Użytkownik ma rozsądną powłokę (/ bin / bash).
Próbowałem odsunąć ~/.ssh/configsię na bok.
scp'ing do tej maszyny od innych z całkowicie różnymi systemami operacyjnymi również kończy się niepowodzeniem.
Dysk nie jest pełny.
Ponowne uruchomienie sshd.

/ var / log / secure zawiera ...

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

Co mogę teraz sprawdzić?

ssh scp

— Schwern
źródło

2

Nie błąd Spodziewam się, ale tylko w przypadku, wykonać ~/.bashrclub ~/.profilelub /etc/bash.bashrclub /etc/profilewydrukować coś na standardowe wyjście? bugzilla.redhat.com/show_bug.cgi?id=20527 . I zakładam, że używasz Linuksa?

— terdon

Nie. Po prostu rozumiem Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4.

— Schwern

Coś w którymkolwiek logu systemowym na hoście docelowym?

— Flup

@ Flup Wygląda normalnie. Opublikowałem to, co pojawia się w logach, kiedy się łączę.

— Schwern

Czy możesz uruchomić strace -f -o /tmp/sshd.strace -p [pid of sshd]na serwerze, spróbować ponownie, a następnie opublikować coś z tego pliku, który wygląda na odpowiedni?

— Flup,

1

Miałem ten sam problem.

Jeśli wykonałeś minimalną instalację Centos, instaluje on tylko pakiety opensshi openssh-server, ale nie openssh-clients. sudo yum install openssh-clientsnaprawi twój problem.

— qux
źródło

Nie mam już dostępu do tej maszyny, ale wydaje się to prawdopodobną odpowiedzią.

— Schwern

4

scpdziała poprzez nawiązanie sshpołączenia ze zdalnym hostem, a następnie uruchomienie innej kopii scpprogramu na tym hoście. Dwie instancje scp komunikują się przez połączenie ssh w celu wykonania transferu plików.

„utracone połączenie” jest drukowane przez scpprogram lokalny , gdy połączenie ssh przedwcześnie znika. Zwykle powodem tego jest to, że scpprogram na zdalnym hoście albo się nie uruchomił, albo zakończył przedwcześnie. Może się tak zdarzyć, ponieważ program scp nie istnieje na zdalnym hoście lub nie ma go w poleceniu PATH, nie jest oznaczony jako wykonywalny, lub zawiesił się po uruchomieniu lub coś w tym stylu.

— Kenster
źródło

0

Ostatnio mieliśmy ten problem na jednym z naszych systemów.

Możemy odpowiednio ssh na serwerze hosta, ale odkryliśmy, że nie możemy ssh z serwera z powrotem na maszynę. To dobre miejsce do zbadania, jeśli nie możesz tego zrobić, nie będziesz mógł korzystać z SCP.

W naszym przypadku w jakiś sposób (być może nieudana instalacja) zastąpił nasze pliki binarne ssh pustymi plikami o wielkości 0 bajtów. Za każdym razem, gdy wykonywano polecenie „ssh”, nic się nie działo.

Przez ponowną instalację klientów openssh poprawiliśmy pliki binarne i scp zaczął działać.

yum reinstall openssh-clients

— Ultimation
źródło