scp 在嘗試將文件從 Linux 複製到 Windows 時卡住

我使用以下 scp 語法將大量文件從 Linux red-hat 5 傳輸到 Windows 機器（在 Temp 目錄下）。

SSH 伺服器已經安裝在 windows 機器上。我在我的 shell 腳本中使用了這一行：

sshpass -p '$password'  /usr/bin/scp -o StrictHostKeyChecking=no  $FILE USER_1@14.187.12.139:'D:/Temp'

大多數情況下文件傳輸成功，但有時scp似乎在文件傳輸過程中卡住了？連接顯示正常，如 ping 等。

我從（很長一段時間後）收到以下錯誤scp：

ssh_exchange_identification: read: Connection reset by peer

1. 為什麼scp不穩定和卡住，這個問題的解決方案是什麼？
2. 其他人有什麼好的選擇scp？（考慮到我需要 100% 的穩定性）

硬體

我不會那麼懷疑的scp。如果它在某些時候工作，這聽起來更像是您的硬體問題：

1. 網卡（linux或windows主機）
2. 接線
3. 交換機/路由器

我會先進行一些基準測試以消除這些項目。您可以看到這些 U&L Q&A 的初學者：

• 如何診斷故障（板載）網路適配器
• Linux網路故障排除與調試

軟體

調試scp&ssh

您可以-v為這兩個命令添加開關以獲得更詳細的輸出。例如：

# generate sample data
$ dd if=/dev/zero of=10MB.testfile bs=1k count=10k
10240+0 records in
10240+0 records out
10485760 bytes (10 MB) copied, 0.0422862 s, 248 MB/s

$ ls -l 10MB.testfile 
-rw-rw---- 1 saml saml 10485760 Jul 29 17:09 10MB.testfile

# test copy 10MB file
$ scp -v 10MB.testfile remoteserver:~
Executing: program /usr/bin/ssh host removeserver, user (unspecified), command scp -v -t -- ~
OpenSSH_5.5p1, OpenSSL 1.0.0e-fips 6 Sep 2011
debug1: Reading configuration data /home/saml/.ssh/config
debug1: Applying options for *
debug1: Applying options for removeserver
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master
Control socket connect(/home/saml/.ssh/master-sam@192.168.1.200:22): Connection refused
debug1: Connecting to 192.168.1.200 [192.168.1.200] port 22.
debug1: Connection established.
debug1: identity file /home/saml/.ssh/id_dsa type 2
debug1: identity file /home/saml/.ssh/id_dsa-cert type -1
debug1: identity file /home/saml/.ssh/qm-dev-servers type 1
debug1: identity file /home/saml/.ssh/qm-dev-servers-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.5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.200' is known and matches the RSA host key.
debug1: Found key in /home/saml/.ssh/known_hosts:30
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/saml/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /home/saml/.ssh/qm-dev-servers
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: setting up multiplex master socket
ControlSocket /home/saml/.ssh/master-sam@192.168.1.200:22 already exists, disabling multiplexing
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.utf8
debug1: Sending command: scp -v -t -- ~
Sending file modes: C0660 10485760 10MB.testfile
Sink: C0660 10485760 10MB.testfile
10MB.testfile                                                                           100%   10MB   3.3MB/s   00:03····
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 10499080, received 4936 bytes, in 4.0 seconds
Bytes per second: sent 2610912.6, received 1227.5
debug1: Exit status 0

您可以添加其他-v開關以獲得更詳細的輸出。例如：

$ scp -vvv ...

Windows 防火牆

在對此進行更多研究時，我遇到了這種解決方法，它可以支持@Gilles 的觀點，即這可能是防火牆問題。sshd解決方案是使用以下命令（以管理員身份）在執行服務的 Windows 端禁用狀態檢查：

% netsh advfirewall set global statefulftp disable

參考

• 奇怪的問題：對等點重置連接

引用自：https://unix.stackexchange.com/questions/84843