我最近將一台伺服器（執行 RHEL AS 5）從 OpenSSH 4 伺服器升級到 OpenSSH 5.2 伺服器。
自升級以來，客戶無法再從電腦上 scp 檔案。他們使用 ssh 用戶端http://ssh.com/。我可以使用 openssh 向機器發送和發送 scp 文件，沒有任何問題。
我們使用“公鑰身份驗證”，他們仍然能夠 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
編輯：conf 檔案中已啟用“子系統 sftp 內部 sftp”，我可以毫無問題地從伺服器發送 sftp 檔案。
編輯：透過指定使用者名稱/密碼來嘗試不使用金鑰也不起作用。恢復到舊版本是可行的，所以這就是我們現在正在做的事情。
順便說一句，我們懷疑這條線
debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0)
可能意味著shell 正在發送一些顯示在ssh 控制台上的內容，但弄亂了scp，但ssh 上似乎沒有發送任何內容（並且.bashrc 看起來很乾淨），並且我無法查看解密的scp 流量以查看是否正在發送某些內容錯。
答案1
「無法 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: 錯誤版本
看起來這個東西正在嘗試使用 sftp 協議而不是直接使用 scp 。預設情況下，OpenSSH 會停用 sftp 子系統。我不知道這個改變是什麼時候做出的，但聽起來很有可能。將其添加到您的 sshd_config 中並查看它是否會改變：
子系統 sftp 內部 sftp
答案2
有很多潛在的問題。首先，您是否檢查過伺服器上的日誌，看看是否有任何線索？升級是否可能更改了用戶端無法使用或未設定為使用的設定。例如，您的伺服器現在需要 SSH2，但客戶端僅使用 SSH1？
日誌檔案可能會提供答案。如果 SCP 用戶端可以進行任何日誌記錄，那也可能會有所幫助。
答案3
這與已修復的 openssh 密鑰漏洞有關。所有易受攻擊的密鑰均已列入黑名單，應重新建立。只需檢查他們是否可以刪除您伺服器的快取指紋即可。完成此操作後，用戶端應向使用者顯示新指紋並詢問是否接受。他們認為 SSH 可能有效，因為應用程式可能會詢問使用者是否接受新金鑰，或在升級後進行初始聯繫。
答案4
我在使用 SSH 用戶端偵錯日誌時遇到了相同的問題，顯示... FileTransferWin/filetransferwin.c:217: 收到錯誤 SSH_FC_OK，錯誤訊息沒有要傳輸的檔案。
經過幾個小時的長時間實驗，我明白SSH 不喜歡傳輸文件形式的資料夾，例如名稱中使用特殊字元的資料夾，即“文件到（傳輸）”將資料夾名稱更改為“Files_to_Transfer”後，它工作得很好。