
최근에 OpenSSH 4 서버에서 OpenSSH 5.2 서버로 서버 한 대(RHEL AS 5 실행)를 업그레이드했습니다.
업그레이드 이후 고객은 더 이상 시스템에서 파일을 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
편집: "Subsystem sftp external-sftp"가 이미 conf 파일에서 활성화되어 있으며 sftp 파일을 문제 없이 서버에서 생성할 수 있습니다.
편집: 사용자 이름/비밀번호를 지정하여 키 없이 시도하는 것도 작동하지 않습니다. 이전 버전으로 되돌리는 것이 작동하므로 현재는 그렇게 하고 있습니다.
그런데 우리는 이 줄을 의심했어요
debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0)
셸이 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: 잘못된 버전
이것은 scp가 아닌 sftp 프로토콜을 직접 사용하려는 것 같습니다. OpenSSH는 기본적으로 sftp 하위 시스템을 비활성화합니다. 언제 이런 변화가 있었는지는 모르겠지만 아마도 그럴 것 같습니다. 이것을 sshd_config에 추가하고 변경 사항이 있는지 확인하십시오.
하위 시스템 SFTP 내부 SFTP
답변2
잠재적인 문제가 많이 있습니다. 먼저, 단서가 있는지 확인하기 위해 서버의 로그를 조사해 보셨나요? 업그레이드로 인해 클라이언트가 사용할 수 없거나 사용하도록 설정되지 않은 설정이 변경되었을 가능성이 있습니까? 예를 들어, 서버에 이제 SSH2가 필요하지만 클라이언트는 SSH1만 사용하고 있습니까?
로그 파일이 답변을 제공할 가능성이 높습니다. SCP 클라이언트가 로깅을 수행할 수 있다면 그것도 도움이 될 수 있습니다.
답변3
이는 수정된 openssh 키 취약점과 관련이 있습니다. 모든 취약한 키는 블랙리스트에 등록되었으므로 다시 생성해야 합니다. 서버의 캐시된 지문을 삭제할 수 있는지 확인하세요. 이 작업이 완료되면 클라이언트는 사용자에게 새 지문을 보여주고 이를 수락하는지 물어봐야 합니다. SSH가 작동할 수 있는 이유는 앱이 사용자에게 새 키를 수락하는지 물었을 수 있거나 업그레이드 후 초기 접촉이 이루어졌기 때문입니다.
답변4
SSH 클라이언트 dibug 로그를 사용하는 동안 동일한 문제가 발생했습니다... FileTransferWin/filetransferwin.c:217: SSH_FC_OK 오류 수신, 오류 메시지 전송할 파일이 없습니다.
몇 시간 동안의 오랜 실험 끝에 나는 SSH가 이름에 사용된 특수 문자(예: 'Files to (Transfer)')와 같은 파일 형식 폴더를 전송하는 것을 좋아하지 않는다는 것을 이해하지 못했습니다. 폴더 이름을 'Files_to_Transfer'로 변경한 후에는 제대로 작동했습니다.