«Сервер отказался от нашего ключа» Только из настройки закладок MobaXterm

«Сервер отказался от нашего ключа» Только из настройки закладок MobaXterm
«Сервер отказался от нашего ключа» Только из настройки закладок MobaXterm - susan_wilkinson @ Unsplash

У меня очень странная проблема, сам не могу разобраться.

Сервер Archlinux с openssh 8.8p1-1 Я не использую пароль для аутентификации, только ключи SSH-RSA. Открытый ключ хранится на сервере внутри /home/stiw47/.ssh/authorized_keys Права доступа к каталогу .ssh — 700, а права доступа к файлу author_keys — 600. Все работало безупречно в течение многих лет, пока несколько дней назад openssh на сервере не был обновлен с 8.7p1-2 до 8.8p1-1. Все по-прежнему работает во всех клиентах ssh/sftp, кроме MobaXterm.

Позвольте мне попытаться объяснить немного лучше:

  • Если я пытаюсь подключиться из FileZilla (sftp) или из JuiceSSH на Android (ssh), все ок с таким же приватным ключом как всегда, как и у всех эти годы.
  • Если я попытаюсь подключиться вручную с терминала на другом компьютере с Linux или из терминала MobaXterm, вручную я имею в виду с помощью команды: ssh -i 'C:\Users\stiw4\Documents\keys\id_rsa' [email protected] - все снова в порядке
  • Если я попытаюсь использовать закладку в MobaXterm (мне нравится закладка), то я получаю Сообщение "Сервер отказался от нашего ключа"

Скриншот области закладок MobaXterm

Я должен упомянуть, что та же самая закладка с тем же закрытым ключом работала нормально до обновления пакета openssh на сервере, а также работает сейчас, если я понизил версию openssh на сервере обратно до 8.7p1-2. Я уже удалил файл MobaXterm known_hosts на компьютере с Windows, но ничего не изменилось.

Я попытался отладить его, запустив на сервере следующее:

sudo `which sshd` -p 2020 -Dd

И подключение из закладки на порт 2020, это лог, я плохо понимаю:

[sudo] password for stiw47:
debug1: sshd version OpenSSH_8.8, OpenSSL 1.1.1l  24 Aug 2021
debug1: private host key #0: ssh-rsa SHA256:uMBMgYez8RvbToK8ZpuVIOT6Kt9DtjwvEEmObduXSaw
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:s/mpg8gbKeFRefGxYjuHYgXFkL8KrklpgivPk9veSXI
debug1: private host key #2: ssh-ed25519 SHA256:MopYaB4XAi8QBkE+RumfZl6IT3y17c3Mu85X+11+wRY
debug1: rexec_argv[0]='/usr/bin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='2020'
debug1: rexec_argv[3]='-Dd'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 2020 on 0.0.0.0.
Server listening on 0.0.0.0 port 2020.
debug1: Bind to port 2020 on ::.
Server listening on :: port 2020.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: sshd version OpenSSH_8.8, OpenSSL 1.1.1l  24 Aug 2021
debug1: private host key #0: ssh-rsa SHA256:uMBMgYez8RvbToK8ZpuVIOT6Kt9DtjwvEEmObduXSaw
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:s/mpg8gbKeFRefGxYjuHYgXFkL8KrklpgivPk9veSXI
debug1: private host key #2: ssh-ed25519 SHA256:MopYaB4XAi8QBkE+RumfZl6IT3y17c3Mu85X+11+wRY
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.0.53 port 50385 on 192.168.0.21 port 2020 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version MoTTY_Release_0.73
debug1: compat_banner: no match: MoTTY_Release_0.73
debug1: permanently_set_uid: 65534/65534 [preauth]
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 [preauth]
debug1: kex: host key algorithm: ssh-ed25519 [preauth]
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_INIT received [preauth]
debug1: rekey out after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 4294967296 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user stiw47 service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "stiw47"
debug1: PAM: setting PAM_RHOST to "192.168.0.53"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user stiw47 service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Received disconnect from 192.168.0.53 port 50385:14: No supported authentication methods available [preauth]
Disconnected from authenticating user stiw47 192.168.0.53 port 50385 [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 64262

Очень странная ситуация для меня, у вас есть идеи?

Спасибо.

Это вызвано тем, что в OpenSSH 8

8 отключены подписи RSA с использованием алгоритма хэширования SHA-1:

В этом выпуске по умолчанию отключены подписи RSA с использованием алгоритма хэширования SHA-1. Это изменение было сделано, поскольку алгоритм хэширования SHA-1 является криптографически неполноценным, и возможно создание коллизий хэшей с выбранным префиксом для <USD$50K

(см. OpenSSH 8.8 - Потенциально несовместимые изменения ).

Вы также можете увидеть соответствующее сообщение в предоставленном журнале:

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

Функциональность этих старых ключей можно восстановить, добавив PubkeyAcceptedKeyTypes +ssh-rsa к /etc/ssh/sshd_config и перезапустив sshd. Однако это должно рассматриваться только как временное решение для замены ключей на ключи, использующие более современные и безопасные алгоритмы, такие как Ed25519 (см. ArchWiki - SSH ключи - Ed25519 ) из-за последствий для безопасности.

Похоже, что причиной того, что эти ключи работают с терминала, является более новая реализация протокола SSH (по сравнению с той, которая используется в MobaXterm), которая автоматически использует SHA-256/512 вместо SHA-1 с этими старыми ключами. Я не смог проверить это, но согласно OpenSSH 8.8 - Потенциально несовместимые изменения:

[...] существующие ключи ssh-rsa будут автоматически использовать более сильный алгоритм, где это возможно.


NevaDev, 3 февраля 2023 г., 18:38