SSH-клиент не предлагает открытый ключ SSH-серверу.

Вопрос или проблема

Я не могу подключиться к своему серверу Ubuntu 22.04 по SSH с одного конкретного хоста. Я могу без проблем подключаться к этому серверу с других хостов. Но когда я пытаюсь подключиться с этого хоста с помощью: ssh -p 5435 -i ~/.ssh/id_ed25519 user@my_server.com -vvv
я получаю:

OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Мар 2022
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 19: include /etc/ssh/ssh_config.d/*.conf не соответствует ни одному файлу
debug1: /etc/ssh/ssh_config строка 21: Применение параметров для *
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/user/.ssh/known_hosts'
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/user/.ssh/known_hosts2'
debug2: разрешение "my_server.com" порт 5435
debug3: resolve_host: поиск my_server.com: 5435
debug3: ssh_connect_direct: вход
debug1: Подключение к my_server.com [xxx.xxx.xxx.xxx] порт 5435.
debug3: set_sock_tos: установка сокета 3 IP_TOS 0x10
debug1: Соединение установлено.
debug1: файл идентификации /home/user/.ssh/id_rsa тип -1
debug1: файл идентификации /home/user/.ssh/id_rsa-cert тип -1
debug1: файл идентификации /home/user/.ssh/id_ecdsa тип -1
debug1: файл идентификации /home/user/.ssh/id_ecdsa-cert тип -1
debug1: файл идентификации /home/user/.ssh/id_ecdsa_sk тип -1
debug1: файл идентификации /home/user/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл идентификации /home/user/.ssh/id_ed25519 тип 3
debug1: файл идентификации /home/user/.ssh/id_ed25519-cert тип -1
debug1: файл идентификации /home/user/.ssh/id_ed25519_sk тип -1
debug1: файл идентификации /home/user/.ssh/id_ed25519_sk-cert тип -1
debug1: файл идентификации /home/user/.ssh/id_xmss тип -1
debug1: файл идентификации /home/user/.ssh/id_xmss-cert тип -1
debug1: файл идентификации /home/user/.ssh/id_dsa тип -1
debug1: файл идентификации /home/user/.ssh/id_dsa-cert тип -1
debug1: Строка версии локального SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
debug1: Удаленная версия протокола 2.0, удаленная версия ПО OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
debug1: compat_banner: совпадение: OpenSSH_8.9p1 Ubuntu-3ubuntu0.10 pat OpenSSH* compat 0x04000000
debug2: fd 3 установка O_NONBLOCK
debug1: Аутентификация к my_server.com:5435 как 'user'
debug3: put_host_port: [my_server.com]:5435
debug3: record_hostkey: найден ключ типа ED25519 в файле /home/user/.ssh/known_hosts:1
debug3: load_hostkeys_file: загружено 1 ключей с [my_server.com]:5435
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: Нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: Нет такого файла или каталога
debug3: order_hostkeyalgs: есть совпадающий ключ типа лучших предпочтений [email protected], использование HostkeyAlgorithms без изменений
debug3: отправка пакета: тип 20
debug1: SSH2_MSG_KEXINIT отправлено
debug3: получение пакета: тип 20
debug1: SSH2_MSG_KEXINIT получено
debug2: локальный клиент KEXINIT предложение
debug2: KEX алгоритмы: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,[email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,[email protected]
debug2: алгоритмы ключей хостов: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256
debug2: шифры ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: шифры stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT предложение
debug2: KEX алгоритмы: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,[email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,[email protected]
debug2: алгоритмы ключей хостов: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: шифры ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: шифры stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug3: kex_choose_conf: будет использоваться строгий порядок KEX
debug1: kex: алгоритм: curve25519-sha256
debug1: kex: алгоритм ключа хоста: ssh-ed25519
debug1: kex: шифр сервер->клиент: [email protected] MAC: <implicit> сжатие: none
debug1: kex: шифр клиент->сервер: [email protected] MAC: <implicit> сжатие: none
debug3: отправка пакета: тип 30
debug1: ожидаем SSH2_MSG_KEX_ECDH_REPLY
debug3: получение пакета: тип 31
debug1: SSH2_MSG_KEX_ECDH_REPLY получен
debug1: Ключ хоста сервера: ssh-ed25519 SHA256:ChCUrM9ZYCR057q60M84kB6pAQa9bQ8ZEHVuw8g7/p0
debug3: put_host_port: [xxx.xxx.xxx.xxx]:5435
debug3: put_host_port: [my_server.com]:5435
debug3: record_hostkey: найден ключ типа ED25519 в файле /home/user/.ssh/known_hosts:1
debug3: load_hostkeys_file: загружено 1 ключей с [my_server.com]:5435
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: Нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: Нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: Нет такого файла или каталога
debug1: Хост '[my-server.com]:5435' известен и совпадает с ключом хоста ED25519.
debug1: Найден ключ в /home/user/.ssh/known_hosts:1
debug3: отправка пакета: тип 21
debug1: ssh_packet_send2_wrapped: сброс последовательности отправки 3
debug2: ssh_set_newkeys: режим 1
debug1: новый ключ после 134217728 блоков
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидаем SSH2_MSG_NEWKEYS
debug3: получение пакета: тип 21
debug1: ssh_packet_read_poll2: сброс последовательности чтения 3
debug1: SSH2_MSG_NEWKEYS получено
debug2: ssh_set_newkeys: режим 0
debug1: новый ключ через 134217728 блоков
debug1: Попытка ключа: /home/user/.ssh/id_rsa
debug1: Попытка ключа: /home/user/.ssh/id_ecdsa
debug1: Попытка ключа: /home/user/.ssh/id_ecdsa_sk
debug1: Попытка ключа: /home/user/.ssh/id_ed25519 ED25519 SHA256:95gTIyyYHXV+UgGYTJiGgC5ulxp3jQoeHmhohQRbIPI
debug1: Попытка ключа: /home/user/.ssh/id_ed25519_sk
debug1: Попытка ключа: /home/user/.ssh/id_xmss
debug1: Попытка ключа: /home/user/.ssh/id_dsa
debug2: pubkey_prepare: завершено
debug3: отправка пакета: тип 5
debug3: получение пакета: тип 7
debug1: SSH2_MSG_EXT_INFO получено
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>
debug1: kex_input_ext_info: [email protected]=<0>
debug3: получение пакета: тип 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug3: отправка пакета: тип 50
debug3: получение пакета: тип 51
debug1: Аутентификации, которые могут продолжаться: publickey
debug3: начать снова, передан другой список publickey
debug3: предпочтительный gssapi-with-mic, keyboard-interactive, password
debug1: Больше нет методов аутентификации для попытки.
[email protected]: Доступ запрещён (publickey).

Похоже, что клиент не предлагает никакой открытый ключ серверу. Должно быть Offering public key:... после Authentications that can continue: publickey

Папка ~/.ssh кажется имеет правильные разрешения:

user@client:~$ ll .ssh
total 24
drwx------ 2 user user 4096 13 Окт 18:54 ./
drwxr-xr-x 8 user user 4096 12 Окт 12:13 ../
-rw------- 1 user user   96 14 Сен 16:50 authorized_keys
-rw------- 1 user user  411 12 Окт 11:42 id_ed25519
-rw-r--r-- 1 user user   96 12 Окт 11:42 id_ed25519.pub
-rw-r--r-- 1 user user  142 12 Окт 11:45 known_hosts

Также я включил ed25519 в ключах:

$ ssh -Q key

ssh-ed25519
[email protected]
...

У меня есть мой открытый ключ в файле authorised_keys сервера, я тщательно проверил это со своим локальным id_ed25519.pub. Они одинаковые. В логах сервера у меня:

$ tail -f /var/log/auth.log

13 Окт 19:19:53 my_server sshd[3131]: Соединение закрыто аутентифицирующимся пользователем user xxx.xxx.xxx.xxx порт 39810 [preauth]

Какова может быть проблема? Я переустановил ssh, но это не помогло. Я также сгенерировал и загрузил новый ключ – та же ошибка. Снова, я могу подключиться к этому серверу как минимум с 2 других хостов с тем же пользователем.

Возможно, у вас установлен PubkeyAuthentication в no где-то на клиенте.

Обычно:

debug3: предпочтительный gssapi-with-mic, publickey, keyboard-interactive, password

должно включать publickey, если PubkeyAuthentication не установлен/установлен в yes:

Указывает, следует ли пытаться аутентификацию по открытому ключу. Аргумент для этого ключевого слова должен быть yes (по умолчанию), no, unbound или host-bound.

% ssh -vvv -i ~/.ssh/id_rsa_github_personal 192.168.1.253 |& grep 'preferred' 
debug3: предпочтительный gssapi-with-mic, publickey, keyboard-interactive, password

Однако, если я переопределю PubkeyAuthentication на no:

% ssh -vvv -o PubkeyAuthentication=no -i ~/.ssh/id_rsa_github_personal 192.168.1.253 |& grep 'preferred'  
debug3: предпочтительный gssapi-with-mic, keyboard-interactive, password

Проверьте, установлен ли у вас PubkeyAuthentication на no в ~/.ssh/config, /etc/ssh/ssh_config или /etc/ssh/ssh_config.d/*:

grep 'PubkeyAuthentication' ~/.ssh/config /etc/ssh/ssh_config /etc/ssh/ssh_config.d/*

Кажется, у вас нет pubkey в ваших предпочтительных методах аутентификации. Проверьте ваши ssh конфигурационные файлы (/etc/ssh/ssh_config и ~/.ssh/config), если опция PreferredAuthentications изменена где-то.

Также на сервере проверьте /etc/ssh/sshd_config, если PubkeyAcceptedKeyTypes включает ed25519, и если PubkeyAuthentication установлен в yes (это должно быть согласно логам).

В противном случае вы можете попробовать новый RSA 4096 ключ.

Ответ или решение

Проблема: SSH-клиент не предлагает публичный ключ SSH-серверу

При попытке подключения к вашему серверу Ubuntu 22.04 по SSH с одного конкретного хоста, вы получаете сообщение о том, что SSH-клиент не предлагает публичный ключ для аутентификации. Несмотря на то что вы можете подключиться к этому серверу с других хостов, проблема заключена только в одном конкретном. Проанализируем ключевые моменты, исходя из предоставленной информации, чтобы определить возможные причины и их решения.

1. Проверка конфигурации SSH-клиента

Одной из возможных причин может быть неправильная настройка в конфигурационных файлах SSH-клиента. Важно убедиться, что в файлах ~/.ssh/config, /etc/ssh/ssh_config и всех файлах в директории /etc/ssh/ssh_config.d/* нет параметра:

PubkeyAuthentication no

Этот параметр отключает аутентификацию по публичным ключам. Проверьте это, выполнив следующую команду:

grep 'PubkeyAuthentication' ~/.ssh/config /etc/ssh/ssh_config /etc/ssh/ssh_config.d/*

Если вы найдете, что значение настроено на no, измените его на yes или просто удалите эту строку.

2. Верификация метода аутентификации

Вы также можете проверить список предпочитаемых методов аутентификации. Оно должно содержать publickey. Выполните команду с опцией -vvv, чтобы получить детальный вывод:

ssh -vvv -i ~/.ssh/id_ed25519 user@my_server.com

Посмотрите на строки с preferred, чтобы убедиться, что publickey входит в список предпочтительных методов. Если его нет, это может означать, что PreferredAuthentications также может быть не выставлен корректно, проверьте аналогичным образом:

grep 'PreferredAuthentications' ~/.ssh/config /etc/ssh/ssh_config /etc/ssh/ssh_config.d/*

3. Проверка сервера SSH

На стороне сервера убедитесь, что в конфигурационном файле /etc/ssh/sshd_config установлены следующие параметры:

PubkeyAuthentication yes

Проверьте также параметр:

PubkeyAcceptedKeyTypes

Убедитесь, что он включает ed25519, так как именно этот тип ключа вы используете. После внесения изменений в конфигурационный файл сервера, не забудьте перезапустить SSH-сервер:

sudo systemctl restart sshd

4. Проверка прав доступа к ключам

Проверьте, что права доступа к файлам вашего SSH-клиента установлены правильно:

  • Директория ~/.ssh должна иметь права 700.
  • Файлы ключей должны иметь права 600 для приватного ключа и 644 для публичного ключа.

Вы привели, что права указаны корректно, однако, для уверенности выполните:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

5. Рекомендации по генерации нового ключа

Если вы всё еще не можете подключиться, попробуйте создать новый SSH-ключ, используя RSA с длинной длиной ключа (например, 4096 бит):

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_new

После создания нового ключа добавьте его в authorized_keys на сервере и попробуйте подключиться снова.

Заключение

Предоставленные шаги должны помочь вам диагностировать и устранить проблемы с аутентификацией SSH на вашем конкретном хосте. Убедитесь, что все настройки как на клиенте, так и на сервере соответствуют рекомендациям. Путём тщательной проверки конфигураций вы сможете найти источник проблемы и восстановить доступ к вашему серверу.

Оцените материал
Добавить комментарий

Капча загружается...