Вопрос или проблема
Я пытаюсь подключиться по ssh к системе Solaris 10U11, используя открытый ключ в списке авторизованных ключей на системе. Кто-нибудь знает, почему меня постоянно просят ввести пароль?
Я думаю, это связано со следующим сообщением об ошибке:
send_pubkey_test: no mutual signature algorithm
Вот некоторые заметки, которые я использовал, чтобы убедиться, что алгоритмы работают, и права доступа к файлам правильные:
Я добавил следующее в клиентский файл .ssh/config, иначе невозможно установить обмен с версией ssh MacOS v13.7:
HostKeyAlgorithms=+ssh-dss
KexAlgorithms +diffie-hellman-group1-sha1,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Проверил, что клиентский файл .ssh/key.pub находится в server .ssh/authorized_keys.
Проверил, что права доступа правильные.
$ ld -ld ~
700
$ ls -ld ~/.ssh
700
$ ls -ld ~/.ssh/authorized_keys
600
$ grep “PubKeyAuthentication” /etc/ssh/sshd_config
PubKeyAuthentication yes
Вот лог с клиента:
$ ssh -v sol10
OpenSSH_9.0p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/USER/.ssh/config
debug1: /Users/USER/.ssh/config line 9: Applying options for *
debug1: /Users/USER/.ssh/config line 36: Applying options for sol10
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.56.21 [192.168.56.21] port 22.
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: identity file /Users/USER/.ssh/id_rsa type 0
debug1: identity file /Users/USER/.ssh/id_rsa-cert type -1
debug1: identity file /Users/USER/.ssh/id_rsa-lin type 0
debug1: identity file /Users/USER/.ssh/id_rsa-lin-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.0
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.5
debug1: compat_banner: no match: Sun_SSH_1.1.5
debug1: Authenticating to 192.168.56.21:22 as 'np'
debug1: load_hostkeys: fopen /Users/USER/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group1-sha1
debug1: kex: host key algorithm: ssh-dss
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-dss SHA256:z1H5tBOkcAOUGKo5aWxufw2E0qsjc/VlYQpNIiZzRaM
debug1: load_hostkeys: fopen /Users/USER/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '192.168.56.21' is known and matches the DSA host key.
debug1: Found key in /Users/USER/.ssh/known_hosts:7
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /Users/USER/.ssh/id_rsa-lin RSA SHA256:x explicit agent
debug1: Will attempt key: /Users/USER/.ssh/id_rsa RSA SHA256:x explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/USER/.ssh/id_rsa-lin RSA SHA256:x explicit agent
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Offering public key: /Users/USER/.ssh/id_rsa RSA SHA256:x explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Next authentication method: keyboard-interactive
Судя по ошибке, send_pubkey_test: no mutual signature algorithm
обычно указывает на более современный клиент OpenSSH, который больше не поддерживает определенные алгоритмы, и поэтому вам нужно их внести в белый список.
Вы можете выполнить:
ssh -Q PubkeyAcceptedAlgorithms
Чтобы получить список разрешенных алгоритмов.
Я взял решение из atlassian помощь
Добавьте PubkeyAcceptedKeyTypes +ssh-rsa в ssh_config
Другое решение:
ssh-keygen -t ed25519 -C "[email protected]"
Чтобы создать новый ключ, добавьте его в ssh/authorized_keys
, и все должно заработать.
Ответ или решение
Проблема с аутентификацией SSH на Solaris 10 через публичные ключи возникает довольно часто, особенно в контексте работы с более современными версиями OpenSSH, такими как OpenSSH 9.0. В вашей ситуации вы столкнулись с проблемой, что система запрашивает пароль, несмотря на то, что ключи настроены. Ошибка "send_pubkey_test: no mutual signature algorithm" указывает на то, что между клиентом и сервером отсутствует согласование по алгоритмам подписи.
Теория
Изменение алгоритмов в OpenSSH
В OpenSSH версии 7.0 и выше некоторые алгоритмы подписи, особенно менее защищенные, были по умолчанию отключены. Это касается алгоритма DSA (ssh-dss) и некоторых RSA ключей, которые используют алогритмы, больше не соответствующие современным стандартам безопасности.
Старая версия SSH на Solaris
Solaris 10 использует более старую реализацию SSH, которая поддерживает ограниченное количество алгоритмов ключевой обмена и подписи. Это создает несовместимость с новейшими версиями OpenSSH, которые могли отказаться поддерживать менее защищенные алгоритмы.
Пример
Из вашего примера видно, что на клиенте используется OpenSSH 9.0, который пытается установить соединение с помощью различных алгоритмов, но не может найти общий алгоритм с сервером Sun_SSH 1.1.5, что приводит к необходимости интервенции.
В вашей конфигурации уже предприняты некоторые шаги, чтобы добавить поддержку устаревших алгоритмов через файл ssh/config
:
HostKeyAlgorithms=+ssh-dss
KexAlgorithms +diffie-hellman-group1-sha1,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Применение
-
Проверка открытых ключей
Убедитесь, что ваш публичный ключ действительно присутствует на сервере в файле
~/.ssh/authorized_keys
и у него корректный формат. Убедитесь, что файл не содержит невидимых символов или ошибок. -
Проверка разрешений
Разрешения на директорию пользователя, директорию
.ssh
и файлauthorized_keys
являются критическими. В вашем случае, они установлены правильно:$ ld -ld ~ 700 $ ls -ld ~/.ssh 700 $ ls -ld ~/.ssh/authorized_keys 600
-
Добавление поддерживаемых алгоритмов
На клиенте в конфигурационный файл SSH следует добавить строку:
PubkeyAcceptedKeyTypes +ssh-rsa
Либо для глобальной настройки можно добавить эту строку в
/etc/ssh/ssh_config
. -
Создание нового ключа
Если вышеуказанные шаги не помогают, рассмотрите возможность создания нового ключа с более современным алгоритмом, таким как
ed25519
:ssh-keygen -t ed25519 -C "your_email@example.com"
После создания нового ключа, добавьте его в
~/.ssh/authorized_keys
на сервере. -
Обновление серверного ПО
В долгосрочной перспективе стоит подумать об обновлении SSH-сервера на Solaris до поддерживаемой версии приятной среды безопасности.
Эти шаги помогут вам устранить проблему ввода пароля при подключении к Solaris 10 через SSH с использованием публичных ключей. Учитывайте, что безопасность всегда должна быть на первом месте, поэтому использование более защищенных алгоритмов предпочтительно.