Сервер OpenSSH отказывается принимать ключ аутентификации

Сервер OpenSSH отказывается принимать ключ аутентификации

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

$ ssh -v -i .ssh/server 192.168.1.100
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data .ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file .ssh/server type -1
debug1: identity file .ssh/server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.100' is known and matches the RSA host key.
debug1: Found key in .ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/server
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

и затем мне приходится вводить пароль, чтобы войти в систему.

Но если у меня уже есть один сеанс, подключенный к этому серверу (который подключен по паролю), то следующее подключение использует ключевую аутентификацию, чтобы избежать ввода пароля.

Если SSH-соединение еще не установлено, я не смогу подключиться без ввода пароля.

Это действительно странно для меня, я проверил MD5 /usr/sbin/sshdмежду новым сервером и другим обычным сервером, они одинаковы. Затем я просто скопировал /etc/ssh/sshd_configс другого обычного сервера на новый сервер и запустил service ssh restart. Проблема все еще существует.

Как мне это исправить?

решение1

Убедитесь, что ваша .sshпапка и файлы внутри нее на клиентском компьютере доступны для чтения только владельцу ( chmod -R 600 .ssh), и что владелец папки и файлов указан правильно ( chownпри необходимости используйте команду ).

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


Редактировать: основываясь на дополнительных отзывах (и некоторых догадках!) - можете ли вы проверить /etc/ssh/sshd_configи посмотреть, установлен ли следующий параметр так, как указано ниже. Если нет, попробуйте отредактировать его.

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Обратите внимание, это предполагает, что вы не вошли в систему удаленно как root.

решение2

В моем случае права доступа к домашнему каталогу были 775ниже 0755или равными.

Полный путь к файлу authorized_keys, т.е. /home/user/.ssh/должен быть 0755или ниже.

решение3

Я исправил свой собственный случай этой ошибки, удалив id_rsa.pubиз .ssh.

Я скопировал id_rsaс другой машины и распространил его на нескольких фиктивных клиентах. Поэтому id_rsaи id_rsa.pubбыли фактически разными ключами, которые вообще не позволяли использовать id_rsa.

Хотя нет сообщения об ошибке, которое бы ясно это указывало. Я понял это по сути случайно, пытаясь привести разные машины в одинаковое состояние.

решение4

После долгих мучений я нашел решение проблемы:

Домашний каталог пользователя не должен иметь разрешения 777или права на запись для всех. В этом случае проверка ключа SSH не пройдет, и вам придется ввести пароль для входа.

Связанный контент