我最近将一台服务器(运行 RHEL AS 5)从 OpenSSH 4 服务器升级到了 OpenSSH 5.2 服务器。
由于升级,客户无法再从机器上 scp 文件。他们使用来自http://ssh.com/的 ssh 客户端。我可以毫无问题地使用 openssh 将文件从机器发送到机器。
我们使用“公钥认证”,他们仍然可以 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 internal-sftp”已经在 conf 文件中启用,我可以毫无问题地从服务器 sftp 文件。
编辑:通过指定用户名/密码尝试不使用密钥也不起作用。恢复到旧版本是可行的,所以这就是我们现在正在做的事情。
顺便说一句,我们怀疑这条线
debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0)
可能意味着 shell 正在发送在 ssh 控制台上显示的内容,但会弄乱 scp,但似乎没有在 ssh 上发送任何内容(并且 .bashrc 似乎很干净),并且我无法查看解密的 scp 流量以查看是否正在发送某些内容错。
“无法 scp 文件”是什么意思?他们得到的错误信息是什么?
检查您的日志(/var/log/syslog、/var/log/messages、/var/log/daemon.log)以查看 SSH 服务器是否抛出任何错误。它们应该非常具有描述性。通过日志和客户的错误,我们应该能够缩小问题的范围。
编辑
您发布的日志表明最可能的问题:
看起来这个东西正在尝试使用 sftp 协议而不是 scp 直接。默认情况下,OpenSSH 禁用 sftp 子系统。我不知道何时进行此更改,但听起来很可能。将此添加到您的 sshd_config 中,看看它是否会改变:
有很多潜在的问题。首先,您是否检查了服务器上的日志以查看是否有任何线索?升级是否可能更改了客户端无法使用或未设置为使用的设置。例如,您的服务器现在是否需要 SSH2,但客户端只使用 SSH1?
日志文件可能会提供答案。如果 SCP 客户端可以进行任何日志记录,那也会很有帮助。
这与已修复的 openssh 密钥漏洞有关。所有易受攻击的密钥都被列入黑名单,应该重新创建。只需检查他们是否可以删除服务器的缓存指纹。完成后,客户端应向用户显示新指纹并询问他们是否接受。他们认为 SSH 可能工作的原因是应用程序可能会询问用户是否接受新密钥,或者在升级后进行了初始联系。
如前所述,有很多可能性。我会从这条线开始:
乍一看,客户端似乎不喜欢它所看到的并以不干净的方式断开连接。
您是否尝试过放回以前版本的 sshd 并查看会发生什么?当客户端尝试在不使用密钥的情况下 ssh 时会发生什么?
我在使用 SSH 客户端调试日志显示时遇到了同样的问题... FileTransferWin/filetransferwin.c:217: Received error SSH_FC_OK, error message No files to transfer。
经过数小时的长时间实验,我不明白 SSH 不喜欢传输文件形式的文件夹,例如名称中使用的特殊字符,即“文件到(传输)”将文件夹名称更改为“文件到传输”后它工作正常。