OpenSSH升级打破了SCP

我最近将一台服务器(运行RHEL AS 5)从OpenSSH 4服务器升级到了OpenSSH 5.2服务器。

由于升级,客户无法从机器scp文件了。 他们使用来自http://ssh.com/的ssh客户端。 我可以使用openssh从机器scp文件没有问题。

我们使用“公钥authentication”,他们仍然可以SSH到机器,但不是SCP文件。

是否有任何已知的 – 显而易见的原因这种不兼容? 如果不是,我该如何深入研究这个问题呢?

这里是来自客户端的日志:

user@srv/home/user> /usr/local/bin/scp -v [email protected]:/home/cdr/test . scp:SshAppCommon/sshappcommon.c:133: Allocating global SshRegex context. scp:Scp2/scp2.c:499: Received error "SSH_FC_OK"., msg: Globbing successful. scp:Scp2/scp2.c:564: Starting transfer... scp:/home/cdr/test scp:SshFCTransfer/sshfc_transfer.c:3018: File list has 2 files. scp:SshFCTransfer/sshfc_transfer.c:2567: Not yet connected, or connection down, waiting... scp:SshFileCopy/sshfilecopy.c:940: Connecting to remote host. (host = xxx.xxx.xxx.51, user = cdr, port = NULL) scp:Scp2/scp2.c:1679: argv[0] = /usr/local/bin/ssh2 scp:Scp2/scp2.c:1679: argv[1] = -l scp:Scp2/scp2.c:1679: argv[2] = cdr scp:Scp2/scp2.c:1679: argv[3] = -v scp:Scp2/scp2.c:1679: argv[4] = -x scp:Scp2/scp2.c:1679: argv[5] = -a scp:Scp2/scp2.c:1679: argv[6] = -o scp:Scp2/scp2.c:1679: argv[7] = clearallforwardings yes scp:Scp2/scp2.c:1679: argv[8] = -o scp:Scp2/scp2.c:1679: argv[9] = passwordprompt %U@%H's password: scp:Scp2/scp2.c:1679: argv[10] = -o scp:Scp2/scp2.c:1679: argv[11] = nodelay yes scp:Scp2/scp2.c:1679: argv[12] = -o scp:Scp2/scp2.c:1679: argv[13] = authenticationnotify yes scp:Scp2/scp2.c:1679: argv[14] = xxx.xxx.xxx.51 scp:Scp2/scp2.c:1679: argv[15] = -s scp:Scp2/scp2.c:1679: argv[16] = sftp debug: Connecting to xxx.xxx.xxx.51, port 22... (SOCKS not used) debug: Ssh2/ssh2.c:2121: Entering event loop. debug: Ssh2Client/sshclient.c:1403: Creating transport protocol. debug: SshAuthMethodClient/sshauthmethodc.c:83: Added "publickey" to usable methods. debug: SshAuthMethodClient/sshauthmethodc.c:83: Added "password" to usable methods. debug: Ssh2Client/sshclient.c:1444: Creating userauth protocol. debug: client supports 2 auth methods: 'publickey,password' debug: Ssh2Common/sshcommon.c:559: local ip = xxx.xxx.xxx.35, local port = 56985 debug: Ssh2Common/sshcommon.c:561: remote ip = xxx.xxx.xxx.51, remote port = 22 debug: SshConnection/sshconn.c:1930: Wrapping... debug: Ssh2/ssh2.c:899: Opening /dev/tty for queries. debug: Remote version: SSH-2.0-OpenSSH_5.2 debug: Ssh2Transport/trcommon.c:1306: Remote version has rekey incompatibility bug. debug: Ssh2Transport/trcommon.c:1308: Remote version is OpenSSH, KEX guesses disabled. debug: Ssh2Transport/trcommon.c:1647: lang s to c: `', lang c to s: `' debug: Ssh2Transport/trcommon.c:1712: c_to_s: cipher aes128-cbc, mac hmac-sha1, compression none debug: Ssh2Transport/trcommon.c:1715: s_to_c: cipher aes128-cbc, mac hmac-sha1, compression none debug: Remote host key found from database. debug: Ssh2Common/sshcommon.c:317: Received SSH_CROSS_STARTUP packet from connection protocol. debug: Ssh2Common/sshcommon.c:367: Received SSH_CROSS_ALGORITHMS packet from connection protocol. debug: server offers auth methods 'publickey,password,keyboard-interactive'. debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/nsdau187" to candidates debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/id_dsa_1024_a" to candidates debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/id_dsa_1024_b" to candidates debug: Constructing and sending signature in publickey authentication. debug: Ssh2AuthPubKeyClient/authc-pubkey.c:772: ssh_client_auth_pubkey_send_signature: reading /devapp_users/nsdtest/.ssh2/nsdau187 debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1751: Public key authentication was successful. debug: Ssh2Common/sshcommon.c:285: Received SSH_CROSS_AUTHENTICATED packet from connection protocol. debug: Ssh2/ssh2.c:650: Returning user input stream to original values. debug: Ssh2Common/sshcommon.c:829: num_channels now 1 scp:SshFCTransfer/sshfc_transfer.c:130: Source file is "raw", and it needs to be parsed. debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0) scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting... scp:SshFileXferClient/sshfilexferc.c:981: ssh_file_client_receive_proc: bad VERSION scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting... scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting... scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting... scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting... scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting... [...] same until the user presses Ctrl+C user@srv/home/user> debug: SshConnection/sshconn.c:405: EOF from channel stream debug: Ssh2ChannelSession/sshchsession.c:1721: received exit status : 0 debug: Ssh2Common/sshcommon.c:803: num_channels now 0 debug: Got session close with exit_status=0 debug: destroying client struct... debug: Ssh2Client/sshclient.c:1478: Destroying client. debug: SshConfig/sshconfig.c:555: Freeing pki. (host_pki != NULL, user_pki = NULL) debug: SshConnection/sshconn.c:1982: Destroying SshConn object. debug: Ssh2Client/sshclient.c:1540: Destroying client completed. debug: SshAuthMethodClient/sshauthmethodc.c:88: Destroying authentication method array. debug: SshAppCommon/sshappcommon.c:146: Freeing global SshRegex context. debug: SshConfig/sshconfig.c:555: Freeing pki. (host_pki = NULL, user_pki = NULL) 

这里是服务器日志的条目

 Jun 3 07:22:36 localhost sshd[19898]: Accepted publickey for cdr from xxx.xxx.xx.x port 53119 ssh2 Jun 3 07:22:36 localhost sshd[19900]: subsystem request for sftp Jun 3 07:22:58 localhost snmpd[8500]: netsnmp_assert index == tmp failed if-mib/data_access/interface.c:467 _access_interface_entry_save_name() Jun 3 07:23:58 localhost last message repeated 4 times 

编辑:“子系统sftp内部sftp”已经在conf文件中启用,我可以从服务器sftp文件没有问题。

编辑:尝试通过指定用户名/密码没有密钥也无法正常工作。 恢复到旧版本的工作,所以这就是我们现在正在做的。

顺便说一句,我们怀疑这条线

 debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0) 

可能意味着shell正在发送一些显示在ssh控制台上的东西,但搞乱了scp,但似乎没有发送任何ssh(而.bashrc似乎干净),我无法查看解密的scpstream量,看看是否有东西被发送错。

“无法scp文件”是什么意思? 他们得到的错误信息是什么?

检查日志(/ var / log / syslog,/ var / log / messages,/var/log/daemon.log)以查看SSH服务器是否正在抛出任何错误。 他们应该是相当具有描述性的。 随着日志和客户的错误,我们应该能够缩小问题的范围。

编辑

您发布的日志表明最可能的问题:

scp:scp2 / scp2.c:1679:argv [16] = sftp

scp:SshFileXferClient / sshfilexferc.c:981:ssh_file_client_receive_proc:错误VERSION

看起来像这个东西是试图使用sftp协议而不是直接scp。 OpenSSH默认禁用sftp子系统。 我不知道什么时候做了这个改变,但听起来很可能。 添加到你的sshd_config,看看它是否改变了事情:

子系统sftp internal-sftp

有很多潜在的问题。 首先,你是否检查过服务器上的日志,看是否有任何线索? 是否有可能升级更改了客户端无法使用或未设置为使用的设置。 例如,您的服务器现在是否需要SSH2,但客户端仅使用SSH1?

日志文件可能会提供答案。 如果SCP客户端可以进行任何日志logging,那也可能有帮助。

这与我修复的openssh密钥漏洞有关。 所有易受攻击的密钥都被列入黑名单,应该重新创build。 只要检查他们是否可以删除您的服务器的caching指纹。 如果这样做,客户应该向用户显示新的指纹,并询问他们是否接受。 他们认为SSH可能工作,应用程序是否可以询问用户是否接受新密钥,或在升级后进行初始联系。

如前所述,有很多的可能性。 我会从这一行开始:

 scp:SshFileXferClient/sshfilexferc.c:981: ssh_file_client_receive_proc: bad VERSION scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting... 

乍看之下,客户看起来不像所看到的那样,并以不洁的方式抛弃了联系。

你有没有尝试把之前版本的sshd放回去,看看会发生什么? 客户端在不使用密钥的情况下尝试SSH时会发生什么?

使用SSH客户端二进制日志显示时遇到同样的问题… FileTransferWin / filetransferwin.c:217:收到错误SSH_FC_OK,错误消息没有要传输的文件。

经过几个小时的长时间的实验,我不知道SSH不喜欢传输文件forms的文件夹,例如在文件名中使用特殊字符,即“文件到(传输)”。将文件夹名更改为“Files_to_Transfer”后,它工作正常。