ssh-вход с публичным ключом все еще запрашивает пароль

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

Я искал по всем темам, которые мог найти по этому поводу, но не могу заставить это работать. Я использовал keygen для создания ключей, copy-id для отправки на сервер и изменил все права доступа на сервере в соответствии с другими постами. Я не вижу ошибок прав доступа или аутентификации, но, возможно, мне нужно включить больше отладки? Вот часть журнала отладки:

debug1: Offering public key: RSA SHA25******* /home/mike/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Интересно, что значит строка “мы не отправили пакет, отключить метод?” После этого я могу войти с паролем.

Сервер: Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-47-generic x86_64)

Вот мой sshd_config:

#       $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $

# Это системный конфигурационный файл sshd. См.
# sshd_config(5) для получения дополнительной информации.

# Этот sshd был скомпилирован с PATH=/usr/bin:/bin:/usr/sbin:/sbin

# Стратегия, используемая для параметров в sshd_config по умолчанию, поставляемом с
# OpenSSH, заключается в том, чтобы указывать параметры с их значением по умолчанию, где
# это возможно, но оставлять их закомментированными. Закомментированные параметры переопределяют
# значение по умолчанию.

Port 2200
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Шифры и ключи
#RekeyLimit default none

# Логирование
#SyslogFacility AUTH
LogLevel VERBOSE

# Аутентификация:
AllowUsers mike
LoginGraceTime 60
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# Ожидайте, что .ssh/authorized_keys2 будет игнорироваться по умолчанию в будущем.
AuthorizedKeysFile      ~/.ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# Чтобы это работало, вам также понадобятся ключи хоста в /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Измените на yes, если вы не доверяете ~/.ssh/known_hosts для
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Не читать файлы ~/.rhosts и ~/.shosts пользователя
#IgnoreRhosts yes

# Чтобы отключить туннелируемые пароли в открытом виде, измените здесь на no!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Измените на yes, чтобы включить пароли с вызовом-ответом (осторожно с проблемами с
# некоторыми модулями PAM и потоками)
ChallengeResponseAuthentication no

# Опции Kerberos
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# Опции GSSAPI
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Установите это на 'yes', чтобы включить аутентификацию PAM, обработку учетных записей
# и обработку сеансов. Если это включено, аутентификация PAM будет
# разрешена через ChallengeResponseAuthentication и
# PasswordAuthentication. В зависимости от конфигурации PAM,
# аутентификация PAM через ChallengeResponseAuthentication может обойти
# настройку "PermitRootLogin without-password".
# Если вы просто хотите, чтобы проверки учетной записи и сеанса PAM выполнялись без
# аутентификации PAM, включите это, но установите PasswordAuthentication
# и ChallengeResponseAuthentication на 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
PrintLastLog no
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
MaxStartups 2
ClientAliveInterval 600
ClientAliveCountMax 0
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# нет пути по умолчанию для баннера
#Banner none

# Разрешить клиенту передавать локальные переменные окружения
AcceptEnv LANG LC_*

# переопределить значение по умолчанию для подсистем
Subsystem       sftp    /usr/lib/openssh/sftp-server

# Пример переопределения настроек для каждого пользователя
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

Изменение строки AuthorizedKeysFile ~/.ssh/authorized_keys на AuthorizedKeysFile .ssh/authorized_keys и перезагрузка службы sshd помогли.

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

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

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

Ваша конфигурация файла sshd_config показывает, что аутентификация по публичному ключу (PubkeyAuthentication) включена, и файл, содержащий авторизованные ключи, правильно настроен на ~/.ssh/authorized_keys. Тем не менее, важно убедиться, что этот файл и родительские директории имеют надлежащие права доступа, что может и не быть очевидным.

  • Права доступа к директориям и файлам:

    Папка ~/.ssh должна иметь права 700, а файл ~/.ssh/authorized_keys600. Для проверки и настройки используйте следующие команды:

    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys

2. Настройки сервера

Ошибки в конфигурации файла sshd_config могут препятствовать корректной аутентификации. Обратите особое внимание на следующее:

  • Ключевой момент: Ваша строка AuthorizedKeysFile ~/.ssh/authorized_keys была изменена на AuthorizedKeysFile .ssh/authorized_keys, что может указывать на проблемы с интерпретацией абсолютного и относительного путей. Абсолютный путь является предпочтительным.

3. Логирование и отладка

Поскольку вы упомянули, что уровень логирования установлен на VERBOSE, это полезно, но вы можете дополнительно активировать отладку на стороне клиента:

ssh -vvv mike@your.server.ip -p 2200

Это даст более детальную информацию о процессе аутентификации и позволит вам увидеть, почему ваш публичный ключ не принимается.

4. Общие проблемы

Несколько других потенциальных проблем, которые стоит проверить:

  • Правильное использование ключа: Убедитесь, что вы используете правильный ключ для подключения. SSH будет пытаться использовать только те ключи, которые хранятся в вашем ssh-agent, если он активирован.

  • Соблюдение условий: Убедитесь, что пользователь, под которым вы подключаетесь (mike), правильно указан в настройках AllowUsers. Убедитесь также, что не нарушены другие условия, такие как настройки PAM и UsePAM.

  • Обновление SSH: Убедитесь, что на сервере установлена актуальная версия SSH. Возможно, стоит обновить.Open SSH до более новой версии, если это возможно.

5. Заключение

Если вы выполнили вышеизложенные шаги и всё равно сталкиваетесь с проблемами, возможно, стоит перегрузить SSH-сервер:

sudo systemctl restart sshd

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

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

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

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