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 Mar 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: match: 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 verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT отправлено
debug3: receive packet: type 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: algorithms ключа хоста: [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]
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: <неявный> сжатие: нет
debug1: kex: шифр клиент->сервер: [email protected] MAC: <неявный> сжатие: нет
debug3: send packet: type 30
debug1: ожидаем SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 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: send packet: type 21
debug1: ssh_packet_send2_wrapped: сбрасываю seqnr отправки 3
debug2: ssh_set_newkeys: режим 1
debug1: rekey out после 134217728 блоков
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидаем SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: ssh_packet_read_poll2: сбрасываю seqnr чтения 3
debug1: SSH2_MSG_NEWKEYS получено
debug2: ssh_set_newkeys: режим 0
debug1: rekey in после 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: send packet: type 5
debug3: receive packet: type 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: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Аутентификации, которые могут продолжаться: publickey
debug3: начать заново, передан другой список publickey
debug3: предпочтительный gssapi-with-mic, keyboard-interactive, password
debug1: Больше нет методов аутентификации для попытки.
[email protected]: Доступ запрещен (publickey).

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

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

Папка .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]
...

Мой публичный ключ находится в authorized_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: OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2

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

Проблема заключалась в том, что в моем /etc/ssh/ssh_config на клиенте PubkeyAuthentication был установлен в no.

Я думал, что если он установлен в yes в /etc/ssh/sshd_config, этого достаточно. Но он должен быть yes в обоих.

Ответ не мой, мне помогли на AskUbuntu Костя и Фриц: https://askubuntu.com/questions/1529881/ssh-client-does-not-offer-public-key-to-ssh-server Мне жаль за дублирование, я не знал, что это медиа – одно и то же.

Сначала вам не следует включать параметр “-i”. Ваши ключи находятся в правильном месте, если только ваша система не настроена иначе.

Затем, похоже, что ваши логи ssh -vvv неполные. Когда я это делаю, у меня больше информации.

Так много возможностей..

  • Версия: openssh должна быть > 6.5
  • Конфигурация: некоторые шифры ed25519 не должны быть отключены..

Это все на данный момент. Если у вас есть больше информации, я могу изменить этот ответ.

Версии:

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

Клиент SSH не отправляет открытый ключ на сервер SSH

Проблема, о которой идет речь, связана с невозможностью подключения к серверу Ubuntu 22.04 через SSH с одного определенного хоста, при этом подключение с других хостов работает без проблем. В данном случае при выполнении команды ssh -p 5435 -i ~/.ssh/id_ed25519 user@my_server.com -vvv клиент SSH не предлагает свой открытый ключ серверу, что нормально (в соответствии с выводом отладки) не должно происходить после сообщения Authentications that can continue: publickey.

Анализ проблемы

Ошибка, скорее всего, вызвана неправильной конфигурацией клиента SSH. В клиентской конфигурации (файл /etc/ssh/ssh_config) параметр PubkeyAuthentication был установлен в no, что препятствовало отправке открытого ключа. Это подтверждено тем, что для успешной аутентификации по ключу должно быть разрешено использование как на сервере (в /etc/ssh/sshd_config), так и на клиенте.

Когда клиент пытается аутентифицироваться, он сначала проверяет доступные методы аутентификации, и в данном случае publickey был указан, но из-за установки PubkeyAuthentication no аутентификация по ключу отключена.

Решение проблемы

Чтобы решить проблему, нужно выполнить следующие шаги:

  1. Изменить настройку клиента SSH:
    Откройте файл /etc/ssh/ssh_config на клиентском компьютере и найдите строку PubkeyAuthentication. Убедитесь, что она установлена в yes. Если строки нет, добавьте:

    PubkeyAuthentication yes
  2. Перезагрузить SSH-соединение:
    После изменения конфигурации попробуйте снова подключиться к серверу. Используйте ssh -vvv для отображения подробной информации о соединении.

  3. Проверьте права доступа на ключи:
    Убедитесь, что права доступа к .ssh и содержащимся в нем файлам настроены правильно. Директория должна иметь права 700, а файлы ключей 600. Например:

    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/id_ed25519
    chmod 600 ~/.ssh/id_ed25519.pub
  4. Убедитесь в наличии всех необходимых ключей:
    Проверьте, что ваш открытый ключ находится в файле ~/.ssh/authorized_keys на сервере. Убедитесь, что содержание открытого ключа аналогично тому, который находится в ~/.ssh/id_ed25519.pub на клиенте.

  5. Убедитесь в совместимости версий SSH:
    Проверьте, что ваша версия OpenSSH на клиенте и сервере актуальна (более 6.5), что гарантирует совместимость с алгоритмами шифрования и аутентификации (например, ed25519 должен быть активирован).

  6. Проверьте другие способы аутентификации:
    Убедитесь, что другие методы аутентификации (например, keyboard-interactive или password) также настроены корректно, если они есть в списке доступных методов аутентификации в выводе.

  7. Проверка логов сервера:
    Проверьте логи на сервере (обычно tail -f /var/log/auth.log), чтобы узнать, получает ли сервер какие-либо данные от клиента и какую ошибку он сообщает, если таковые имеются.

Если вы внесете все эти изменения и верно выполните указанные шаги, это должно привести к успешной аутентификации по ключу.

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

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