Вопрос или проблема
У меня есть более ранняя версия Ubuntu 24.04, где authorized_keys работает так же, как и в 22.04. Но теперь у меня есть несколько новых серверов Ubuntu 24.04, и на (по крайней мере) двух из них ssh войти в систему продолжает запрашивать пароль, даже когда на сервере есть открытый ключ ed25519.
Вот вывод ssh -v [email protected]
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
debug1: Чтение конфигурационных данных C:\\Users\\myuser/.ssh/config
debug1: Подключение к 10.6.5.55 [10.6.5.55] порт 22.
debug1: Соединение установлено.
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_rsa тип 0
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_rsa-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ecdsa тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ecdsa-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ecdsa_sk тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ed25519 тип 3
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ed25519-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ed25519_sk тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ed25519_sk-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_xmss тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_xmss-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_dsa тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_dsa-cert тип -1
debug1: Локальная строка версии SSH-2.0-OpenSSH_for_Windows_9.5
debug1: Удалённая версия протокола 2.0, удалённая версия программного обеспечения OpenSSH_9.6p1 Ubuntu-3ubuntu13.5
debug1: compat_banner: match: OpenSSH_9.6p1 Ubuntu-3ubuntu13.5 pat OpenSSH* compat 0x04000000
debug1: Аутентификация к 10.6.5.55:22 как 'myuser'
debug1: load_hostkeys: fopen C:\\Users\\myuser/.ssh/known_hosts2: Нет такого файла или каталога
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: Нет такого файла или каталога
debug1: SSH2_MSG_KEXINIT отправлено
debug1: SSH2_MSG_KEXINIT получено
debug1: kex: алгоритм: ecdh-sha2-nistp256
debug1: kex: алгоритм ключа хоста: ssh-ed25519
debug1: kex: шифр сервер->клиент: [email protected] MAC: сжатие: нет
debug1: kex: шифр клиент->сервер: [email protected] MAC: сжатие: нет
debug1: ожидание SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY получено
debug1: Ключ хоста сервера: ssh-ed25519 SHA256:m26CMqvOVY+w3YtxEkefbPbXXN5g5tkco4jVQ4HJvCo
debug1: load_hostkeys: fopen C:\\Users\\myuser/.ssh/known_hosts2: Нет такого файла или каталога
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: Нет такого файла или каталога
debug1: Хост '10.6.5.55' известен и соответствует ключу хоста ED25519.
debug1: Найден ключ в C:\\Users\\myuser/.ssh/known_hosts:40
debug1: ssh_packet_send2_wrapped: сбрасывается send seqnr 3
debug1: rekey out после 134217728 блоков
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидание SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: сбрасывается read seqnr 3
debug1: SSH2_MSG_NEWKEYS получено
debug1: rekey in после 134217728 блоков
debug1: get_agent_identities: ssh_get_authentication_socket: Нет такого файла или каталога
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_rsa RSA SHA256:uuLy4rRze6KhjmYigHyTdSS+SKLDMLMk4FKgot0pwKo
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_ecdsa
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_ecdsa_sk
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_ed25519 ED25519 SHA256:u4rAvxwVLoncdn+bxKPgFrqyZghfgGwS2N6PBAABUP3Q
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_ed25519_sk
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_xmss
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO получено
debug1: kex_input_ext_info: server-sig-algs=[email protected],[email protected],rsa-sha2-512,rsa-sha2-256>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug1: Аутентификации, которые могут продолжаться: publickey,password
debug1: Следующий метод аутентификации: publickey
debug1: Предложение открытого ключа: C:\\Users\\myuser/.ssh/id_rsa RSA SHA256:uuLy4rRze6KhjmYigHyTdSS+SKLDMLMk4FKgot0pwKo
debug1: Аутентификации, которые могут продолжаться: publickey,password
debug1: Попытка закрытого ключа: C:\\Users\\myuser/.ssh/id_ecdsa
debug1: Попытка закрытого ключа: C:\\Users\\myuser/.ssh/id_ecdsa_sk
debug1: Предложение открытого ключа: C:\\Users\\myuser/.ssh/id_ed25519 ED25519 SHA256:u4rAvxwVLoncdn+bxKPgFrqyZghfgGwS2N6PBAABUP3Q
debug1: Сервер принимает ключ: C:\\Users\\myuser/.ssh/id_ed25519 ED25519 SHA256:u4rAvxwVLoncdn+bxKPgFrqyZghfgGwS2N6PBAABUP3Q
debug1: Аутентификации, которые могут продолжаться: publickey,password
debug1: Попытка закрытого ключа: C:\\Users\\myuser/.ssh/id_ed25519_sk
debug1: Попытка закрытого ключа: C:\\Users\\myuser/.ssh/id_xmss
debug1: Попытка закрытого ключа: C:\\Users\\myuser/.ssh/id_dsa
debug1: Следующий метод аутентификации: password
Получено отключение от 10.6.5.55 порт 22:2: Слишком много неудач при аутентификации
Отключено от 10.6.5.55 порт 22
В качестве сравнения работающий сервер создает следующий вывод (ssh -v [email protected]):
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
debug1: Чтение конфигурационных данных C:\\Users\\myuser/.ssh/config
debug1: Подключение к 10.6.5.52 [10.6.5.52] порт 22.
debug1: Соединение установлено.
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_rsa тип 0
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_rsa-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ecdsa тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ecdsa-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ecdsa_sk тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ed25519 тип 3
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ed25519-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ed25519_sk тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_ed25719_sk-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_xmss тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_xmss-cert тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_dsa тип -1
debug1: файл идентификации C:\\Users\\myuser/.ssh/id_dsa-cert тип -1
debug1: Локальная строка версии SSH-2.0-OpenSSH_for_Windows_9.5
debug1: Удалённая версия протокола 2.0, удалённая версия программного обеспечения OpenSSH_9.6p1 Ubuntu-3ubuntu13.5
debug1: compat_banner: match: OpenSSH_9.6p1 Ubuntu-3ubuntu13.5 pat OpenSSH* compat 0x04000000
debug1: Аутентификация к 10.6.5.52:22 как 'myuser'
debug1: load_hostkeys: fopen C:\\Users\\myuser/.ssh/known_hosts2: Нет такого файла или каталога
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: Нет такого файла или каталога
debug1: SSH2_MSG_KEXINIT отправлено
debug1: SSH2_MSG_KEXINIT получено
debug1: kex: алгоритм: curve25519-sha256
debug1: kex: алгоритм ключа хоста: ssh-ed25519
debug1: kex: шифр сервер->клиент: [email protected] MAC: сжатие: нет
debug1: kex: шифр клиент->сервер: [email protected] MAC: сжатие: нет
debug1: ожидание SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY получено
debug1: Ключ хоста сервера: ssh-ed25519 SHA256:tlS1ToT7k42BWs8WklWOXcwp9NKzRcAv4V0IJvyPuBk
debug1: load_hostkeys: fopen C:\\Users\\myuser/.ssh/known_hosts2: Нет такого файла или каталога
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: Нет такого файла или каталога
debug1: Хост '10.6.5.52' известен и соответствует ключу хоста ED25519.
debug1: Найден ключ в C:\\Users\\myuser/.ssh/known_hosts:37
debug1: ssh_packet_send2_wrapped: сбрасывается send seqnr 3
debug1: rekey out после 134217728 блоков
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидание SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: сбрасывается read seqnr 3
debug1: SSH2_MSG_NEWKEYS получено
debug1: rekey in после 134217728 блоков
debug1: get_agent_identities: ssh_get_authentication_socket: Нет такого файла или каталога
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_rsa RSA SHA256:uuLy4rRze6KhjmYigHyTdSS+SKLDMLMk4FKgot0pwKo
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_ecdsa
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_ecdsa_sk
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_ed25519 ED25519 SHA256:ubuYzcbrtncdn+bxKPgFrqyZghfgGwS2N6PBAABUP3QtlS1ToT7k42BWs8WklWOXcwp9NKzRcAv4V0IJvyPuBk
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_ed25519_sk
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_xmss
debug1: Попытка ключа: C:\\Users\\myuser/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO получено
debug1: kex_input_ext_info: server-sig-algs=[email protected],[email protected],rsa-sha2-512,rsa-sha2-256>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug1: Аутентификации, которые могут продолжаться: publickey,password
debug1: Следующий метод аутентификации: publickey
debug1: Предложение открытого ключа: C:\\Users\\myuser/.ssh/id_rsa RSA SHA256:uuLy4rRze6KhjmYigHyTdSS+SKLDMLMk4FKgot0pwKo
debug1: Сервер принимает ключ: C:\\Users\\myuser/.ssh/id_rsa RSA SHA256:uuLy4rRze6KhjmYigHyTdSS+SKLDMLMk4FKgot0pwKo
Аутентифицировано к 10.6.5.52 ([10.6.5.52]:22) с использованием "publickey".
debug1: канал 0: новая сессия [client-session] (инактивный таймаут: 0)
debug1: Запрос [email protected]
debug1: Вход в интерактивную сессию.
debug1: pledge: файловая система
debug1: ENABLE_VIRTUAL_TERMINAL_INPUT поддерживается. Чтение VTSequence с консоли
debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING поддерживается. Консоль поддерживает ansi парсинг
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: client_input_hostkeys: поиск C:\\Users\\myuser/.ssh/known_hosts для 10.6.5.52 / (none)
debug1: client_input_hostkeys: поиск C:\\Users\\myuser/.ssh/known_hosts2 для 10.6.5.52 / (none)
debug1: client_input_hostkeys: файл ключей хоста C:\\Users\\myuser/.ssh/known_hosts2 отсутствует
debug1: client_input_hostkeys: нет новых или устаревших ключей от сервера
debug1: Удалённо: /myuser/.ssh/authorized_keys:2: параметры ключа: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Удалённо: /myuser/.ssh/authorized_keys:2: параметры ключа: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: pledge: fork
debug1: client_input_channel_req: канал 0 rtype exit-status reply 0
debug1: client_input_channel_req: канал 0 rtype [email protected] reply 0
debug1: канал 0: свободен: client-session, nchannels 1
Соединение с 10.6.5.52 закрыто.
Передано: отправлено 5416, получено 5496 байт, за 10.3 секунды
Байты в секунду: отправлено 525.7, получено 533.5
debug1: Статус выхода 0
Файл ssh_config идентичен на обоих серверах:
Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP no
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,[email protected]
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
# UserKnownHostsFile ~/.ssh/known_hosts.d/%k
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
IdentityFile ~/.ssh/id_ed25519
Есть идеи, где найти виновника?
С уважением,
hank
Нет необходимости больше об этом думать, была одна неправильная настройка, и проблема была не в аутентификации ключа.
Ответ или решение
Для устранения проблемы с аутентификацией по ключу SSH на новых серверах Ubuntu 24.04, мы рассмотрим несколько возможных причин и шагов для их исправления. Ваша ситуация, когда правильный публичный ключ уже установлен, но SSH по-прежнему запрашивает пароль, может указывать на проблемы с конфигурацией или правами доступа.
1. Проверка прав доступа
Правильные права на файлы и директории SSH критически важны для их корректной работы. Проверьте следующие параметры:
-
Директория
~/.ssh
должна иметь права700
(только владелец может читать, записывать и выполнять):chmod 700 ~/.ssh
-
Файл
~/.ssh/authorized_keys
должен иметь права600
(только владелец может читать и записывать):chmod 600 ~/.ssh/authorized_keys
-
Убедитесь, что у вашего домашнего каталога (обычно это
~
) есть права755
или700
:chmod 755 ~
2. Проверка конфигурации SSH-сервера
Убедитесь, что в конфигурационном файле SSH-сервера (/etc/ssh/sshd_config
) установлены следующие параметры:
PubkeyAuthentication yes
— убедитесь, что этот параметр не закомментирован.AuthorizedKeysFile .ssh/authorized_keys
— проверьте правильность указания файла с авторизованными ключами.PermitRootLogin
— если вы пытаетесь войти под пользователем root, убедитесь, что это разрешено (чтобы избежать риска безопасности, рекомендуется использовать обычного пользователя).
После внесения изменений перезапустите SSH-сервер:
sudo systemctl restart ssh
3. Проверка конфигурации клиента SSH
Поскольку вы подключаетесь с клиента Windows, убедитесь, что файл конфигурации клиента (C:\\Users\\myuser/.ssh/config
) настроен правильно. Вы можете добавить прямую ссылку на используемый ключ:
Host 10.6.5.55
User myuser
IdentityFile C:\\Users\\myuser\\.ssh\\id_ed25519
4. Устранение проблем с агентом SSH
Проблемы с аутентификацией могут также возникать, если ваш агент SSH не обрабатывает ключи корректно. Используйте команду ssh-add
для добавления вашего приватного ключа в агент:
ssh-add ~/.ssh/id_ed25519
Если агент SSH отсутствует или не активирован, вам нужно будет его запустить.
5. Диагностика с помощью подробного логирования
Чтобы лучше понять, где может заключаться причина неудачи, используйте дополнительные опции при подключении:
ssh -vvv [email protected]
Эта команда даст более подробный вывод, который может указать на наличие конкретной проблемы.
Заключение
Если после проверки всех вышеуказанных действий проблема сохраняется, возможно, существуют менее распространенные ошибки, например, конфликты с другими правилами брандмауэра или сетевыми настройками. Приведение всех компонентов в порядок должно помочь вам устранить проблему с аутентификацией по SSH на новых серверах Ubuntu 24.04.