我使用以下 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
- 为什么
scp
不稳定并且卡住,这个问题有什么解决办法吗? - 还有什么其他好的选择
scp
? (考虑到我需要100%的稳定性)
答案1
硬件
我不会那么怀疑scp
。如果它有时能正常工作,这听起来更像是您的以下任一方面的硬件问题:
- 网卡(linux或windows主机)
- 接线
- 交换机/路由器
我会先执行一些基准测试来消除这些项目。您可以查看以下针对初学者的 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
就我而言,情况很简单:目标计算机磁盘空间不足。