Недавно я обновил один сервер (работающий под управлением RHEL AS 5) с сервера OpenSSH 4 до сервера OpenSSH 5.2.
После обновления клиент больше не может scp-файлы с машины. Они используют ssh-клиент изhttp://ssh.com/. Я могу без проблем копировать файлы с машины и на нее с помощью команды scp, используя 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
Редактировать: «Subsystem sftp internal-sftp» уже включена в файле конфигурации, и я могу без проблем загружать файлы sftp с сервера.
Редактировать: Попытка без ключей с указанием имени пользователя/пароля тоже не работает. Возврат к старой версии работает, так что это то, что мы делаем сейчас.
Кстати, мы подозревали эту линию.
debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0)
может означать, что оболочка отправляет что-то, что отображается в консоли ssh, но портит scp, но, похоже, по ssh ничего не отправляется (и .bashrc кажется чистым), и я не могу просмотреть расшифрованный трафик scp, чтобы увидеть, отправляется ли что-то неправильно.
решение1
Что еще означает "unable to scp files"? Какое сообщение об ошибке они получают?
Проверьте ваши логи (/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 не любит передавать файлы из папок, в названии которых используются специальные символы, например, «Файлы в (Передача)». После изменения имени папки на «Файлы_для_передачи» все заработало нормально.