scp "загублений зв'язок", але ssh працює нормально


10

Почав відмовлятися від scp, сервер, на який я можу схуднути.

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

З scp -v -vмоменту я бачу, що з'єднання проходить успішно, і передача виявляється успішною, але жоден файл не з’являється з іншого боку.

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

Це машина CentOS 5.9.

Те, що я перевірив ...

  • Я маю дозвіл писати в цей каталог.
  • Користувач має чутливу оболонку (/ bin / bash).
  • Я спробував перенести свою ~/.ssh/configдорогу.
  • scp'ing до цієї машини від інших з абсолютно іншими операційними системами також не вдається.
  • Диск не повний.
  • Перезапуск sshd.

/ var / log / secure містить ...

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

Що я можу перевірити далі?


2
Чи не помилка , я б очікувати, але тільки в тому випадку, робити ~/.bashrcабо ~/.profileабо /etc/bash.bashrcабо /etc/profileнадрукувати що - або STDOUT? bugzilla.redhat.com/show_bug.cgi?id=20527 . І я припускаю, що ви використовуєте Linux?
тердон

Ні. Я просто отримую звичайне Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4.
Шверн

Щось у будь-якому з системних журналів на цільовому хості?
Flup

@Flup Виглядає нормально. Я опублікував, що відображається в журналах, коли я підключаюся.
Шверн

Ви можете запустити strace -f -o /tmp/sshd.strace -p [pid of sshd]на сервері, спробуйте ще раз, а потім опублікувати що-небудь із цього файлу, який виглядає релевантним?
Flup

Відповіді:


1

Мав те саме питання.

Якщо ви зробили мінімальну установку Centos, він встановлює лише пакети opensshта openssh-serverпакети, але не їх openssh-clients. sudo yum install openssh-clientsвиправить вашу проблему.


У мене більше немає доступу до цієї машини, але це здається вірогідною відповіддю.
Schwern

4

scpпрацює, встановивши sshз'єднання з віддаленим хостом, потім запустивши іншу копію scpпрограми на цьому хості. Два екземпляри scp спілкуються через ssh-з'єднання для здійснення передачі файлів.

"втрачене з'єднання" друкується локальною scpпрограмою, коли ssh-з'єднання передчасно припиняється. Звичайною причиною цього є scpпрограма на віддаленому хості або не вдалося запустити, або ж вона закінчилася передчасно. Це могло статися тому, що програми scp не існує на віддаленому хості, або це не у вашій команді PATH, або вона не позначена виконуваною, або вона вийшла з ладу після запуску, або щось у цих рядках.


0

Нещодавно у нас виникла ця проблема в одній із наших систем.

Ми могли належним чином ssh на хост-сервер, але виявили, що не можемо ssh з сервера повернутися на машину. Це хороше місце для дослідження, якщо ви не можете цього зробити, ви не зможете використовувати SCP.

У нашому випадку якимось чином (можливо, встановлене з утилітою) замінили наші ssh бінарні файли порожніми файлами 0 байтами. Щоразу, коли «ssh» виконувались, нічого не сталося.

Перевстановивши openssh-клієнтів, ми виправили бінарні файли і scp приступив до роботи.

yum reinstall openssh-clients

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.