Вопрос или проблема
У меня есть проблема, из-за которой старые клиенты не могут подключиться к текущим версиям (v8.x) сервера openssh. Я знаком с добавлением ssh-rsa, ssh-dss в список доступных типов ключей, но это, кажется, не помогает в этом вопросе.
Один из наших поставщиков является клиентом, и нет возможности передавать флаги. Когда они пытаются подключиться, я получаю следующее сообщение:
Apr 16 20:57:13 server sshd[70429]: Unable to negotiate with 10.0.3.39 port 49100: no matching host key type found. Their offer: [email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss [preauth]
Я добавил следующее в /etc/ssh/sshd_config.d/10-test.conf
KexAlgorithms=+diffie-hellman-group1-sha1
[email protected],[email protected],ssh-rsa,ssh-dss
PubkeyAcceptedAlgorithms=+ssh-rsa,ssh-dss
Также пробовал без ‘=’, но это не влияет. Вот отладочный вывод:
[centos@ip-10-0-3-39 ~]$ ssh -vv -i test [email protected]
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.3.225 [10.0.3.225] port 22.
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file test type -1
debug1: identity file test-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: match: OpenSSH_8.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,[email protected]
debug2: kex_parse_kexinit: hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96
debug2: kex_parse_kexinit: hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,[email protected]
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
debug2: kex_parse_kexinit: [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none
no hostkey alg
У кого-нибудь есть какие-либо идеи, потому что я в тупике.
Спасибо!
Сначала попробуйте в командной строке с различными опциями
ssh -vv -A -t -oHostKeyAlgorithms=+ssh-dss [email protected]
Затем обновите файл ssh_config соответственно
.
Ответ или решение
Прежде чем углубиться в решение проблемы с SSH-соединением, давайте рассмотрим теорию, касающуюся данного вопроса.
Теория (Theory)
SSH (Secure Shell) — это протокол сетевой безопасности, используемый для безопасного входа на удаленные серверы и передачи данных. Существует несколько версий OpenSSH, каждая из которых поддерживает различные алгоритмы шифрования и аутентификации. Сторона, запрашивающая соединение (клиент), и сервер должны договориться об использовании одного из общих поддерживаемых алгоритмов для установки безопасного соединения.
Когда возникает ошибка "Unable to negotiate: no matching host key type found", это означает, что клиент и сервер не смогли согласовать общий алгоритм ключа хоста. Это может происходить по нескольким причинам:
-
Устаревшие алгоритмы: В более новых версиях OpenSSH удалена поддержка устаревших и небезопасных алгоритмов, таких как
ssh-rsaиssh-dss. Это ведет к проблемам совместимости с более старыми клиентами или не обновленными серверами. -
Некорректные настройки конфигурации: Неправильная конфигурация
sshd_configна сервере илиssh_configна клиенте может препятствовать согласованию поддерживаемых алгоритмов. -
Политики безопасности: Некоторые организации могут целенаправленно отключать устаревшие алгоритмы в целях усиления безопасности.
Пример (Example)
В предоставленном вами сценарии попытки настроить конфигурацию sshd_config не принесли результатов. Это свидетельствует о том, что указанные алгоритмы не удается правильно согласовать между клиентом и сервером. Сервер предлагает множество алгоритмов в предложении, но клиент, использующий OpenSSH 5.3, не поддерживает новые и более безопасные алгоритмы, предложенные сервером OpenSSH 8.7.
Применение (Application)
Возможные решения:
-
Актуализация клиента: Один из наиболее долгосрочных и безопасных подходов — обновление клиента до более новой версии OpenSSH. Однако, как вы указали, обновление клиента зависит от возможности вашего вендора.
-
Отмена жестких политик конфигурации на сервере: Если обновление клиента невозможно, временным решением может стать временное изменение конфигурации на сервере следующим образом:
- Убедитесь, что вы указываете поддерживаемые клиентом алгоритмы в файле конфигурации
/etc/ssh/sshd_config.
Пример добавления:
HostKeyAlgorithms=+ssh-rsa,ssh-dss PubkeyAcceptedAlgorithms=+ssh-rsa,ssh-dssЗатем перезапустите сервис SSH:
sudo systemctl restart sshdОбратите внимание: включение этих алгоритмов может повысить риск безопасности. Это следует делать только временно и исключительно в случае совместимости.
- Убедитесь, что вы указываете поддерживаемые клиентом алгоритмы в файле конфигурации
-
Отладка через командную строку: Попробуйте подключиться к серверу, используя команду с расширенными опциями для отладки:
ssh -vv -oHostKeyAlgorithms=+ssh-dss [email protected] -
Использование SSH-конфигураций для конкретных хостов: Если проблема возникает с подключением к конкретному серверу, можно настроить файл конфигурации клиента
.ssh/configдля данного хоста, добавив в него нужные настройки алгоритмов.Пример:
Host example.com HostKeyAlgorithms=+ssh-rsa,ssh-dss PubkeyAcceptedAlgorithms=+ssh-rsa,ssh-dss -
Консультирование с вендором: Если ваше сотрудничество с вендором критически важно, обсудите возможные обновления их программного обеспечѐния.
-
Создание безопасного канала/туннеля: В крайнем случае, если решение проблемы невозможно из-за стороннего ПО, можно настроить VPN или порт-форвардинг, создавая туннель для более актуального клиента/сервера, создавая таким образом мост между старыми и новыми стандартами.
В заключение, подход к решению проблемы "Unable to negotiate: no matching host key type found" должен базироваться на конечной цели вашей безопасности и доступных возможностей обновления. Используете вы временные меры или инициируете процесс модернизации клиента, важно помнить о балансе между доступностью и безопасностью.