題 scp“丟失連接”,但ssh工作正常


我可以服務的服務器開始拒絕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機器。

我檢查過的事情......

  • 我有權寫入該目錄。
  • 用戶有一個明智的shell(/ bin / bash)。
  • 我試著移動我的 ~/.ssh/config 走開了。
  • 從完全不同的操作系統的其他人scp到該機器也失敗了。
  • 磁盤未滿。
  • 重啟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

我接下來可以檢查什麼?


9
2018-04-04 14:13


起源


不是我期望的錯誤,但為了以防萬一,做你的 ~/.bashrc 要么 ~/.profile 要么 /etc/bash.bashrc 要么 /etc/profile 什麼東西打印到STDOUT? bugzilla.redhat.com/show_bug.cgi?id=20527。我假設您使用的是Linux? - terdon
不。我只是平常 Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4。 - Schwern
目標主機上的任何系統日誌中的任何內容? - Flup
@Flup看起來很正常。當我連接時,我發布了日誌中顯示的內容。 - Schwern
你能開始嗎? strace -f -o /tmp/sshd.strace -p [pid of sshd] 在服務器上,再試一次,然後發布看起來相關的文件中的任何內容? - Flup


答案:


有同樣的問題。

如果您進行了Centos的最小安裝,它只會安裝 openssh 和 openssh-server 包但不是 openssh-clientssudo yum install openssh-clients 將解決您的問題。


1
2017-11-12 20:41



我再也無法訪問該機器,但這似乎是一個可能的答案。 - Schwern


scp 通過製作一個 ssh 連接到遠程主機,然後啟動另一個副本 scp 該主持人的節目。兩個scp實例通過ssh連接進行通信以執行文件傳輸。

“失去聯繫”由當地人印製 scp 當ssh連接過早掉線時編程。通常的原因是 scp 遠程主機上的程序無法啟動或者過早退出。這可能是因為遠程主機上不存在scp程序,或者它不在命令PATH中,或者它沒有標記為可執行文件,或者在啟動後崩潰,或者沿著這些行崩潰。


4
2017-11-12 21:50





我們最近在我們的一個系統上遇到過這個問題。

我們可以適當地ssh到主機服務器上,但發現我們無法從服務器ssh回到機器上。這是一個調查的好地方,如果你不能這樣做,那麼你將無法使用SCP。

在我們的例子中,不知何故(可能是一個拙劣的安裝)已經用0字節的空文件替換了我們的ssh二進製文件。每當執行“ssh”時,什麼也沒發生。

通過重新安裝openssh-clients,我們糾正了二進製文件,scp開始工作。

yum reinstall openssh-clients 


0
2018-03-13 13:22