尝试将文件从 Linux 复制到 Windows 时 scp 卡住

尝试将文件从 Linux 复制到 Windows 时 scp 卡住

我使用以下 scp 语法将大量文件从 Linux red-hat 5 传输到 Windows 计算机(在 Temp 目录下)。

Windows 机器上已经安装了 SSH 服务器。我在 shell 脚本中使用这一行:

sshpass -p '$password'  /usr/bin/scp -o StrictHostKeyChecking=no  $FILE [email protected]:'D:/Temp'

大多数情况下文件传输成功,但有时scp在文件传输过程中似乎会卡住?连接显示正常,如 ping 等。

我收到以下错误scp(很长一段时间后):

ssh_exchange_identification: read: Connection reset by peer
  1. 为什么scp不稳定并且卡住,这个问题有什么解决办法吗?
  2. 还有什么其他好的选择scp? (考虑到我需要100%的稳定性)

答案1

硬件

我不会那么怀疑scp。如果它有时能正常工作,这听起来更像是您的以下任一方面的硬件问题:

  1. 网卡(linux或windows主机)
  2. 接线
  3. 交换机/路由器

我会先执行一些基准测试来消除这些项目。您可以查看以下针对初学者的 U&L 问答:

软件

调试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/[email protected]: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/[email protected]: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

参考

答案2

我遇到了这个问题,通过 2 个 NAT 在端口 22 上从 Linux 机器到 Linux 机器进行 scp'ing。由于我无法控制 Windows 机器或 NAT 盒,只能控制 2 台 Linux 机器,所以我的解决方案是将 ssh 服务器从端口 22 切换到 2222一切开始顺利进行。

同样的问题,从 Windows 机器到 linux 机器的 scping 工作,从 linux 机器到我的机器的 scping 工作,但是从我的机器到 linux 服务器发送数据以服务器(或中间 NAT 盒上的防火墙)发送 TCP 结束RST 数据包发送到我的服务器。

scp症状:

debug2: channel 0: written 31 to efd 7
rapport.pdf                                                                             0%    0     0.0KB/s   --:-- ETAdebug3: send packet: type 1
packet_write_wait: Connection to 192.168.1.2 port 22: Broken pipe
lost connection

通过 ssh 进行 git 的症状:

debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Counting objects: 176, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (90/90), done.
debug2: channel 0: rcvd adjust 98457
debug3: send packet: type 176)   
packet_write_wait: Connection to 192.168.1.2 port 22: Broken pipe
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly

一些进一步的挖掘让我https://serverfault.com/questions/411629/tcp-connection-reset-in-linuxstrange-packet-loss-but-not-on-windows 如果您只能控制本地 Linux 机器,那么有一个解决方案:

 there is a broken firewall along the path that is filtering all IP packets that use TCP Timestamp option. 

因此,为了保持端口 22 上的工作正常,我在我的机器上运行了以下命令:

echo 0 | sudo tee /proc/sys/net/ipv4/tcp_timestamps

答案3

就我而言,情况很简单:目标计算机磁盘空间不足。

相关内容