
Я попытался использовать аутентификацию с открытым ключом на своем новом сервере и столкнулся с этой проблемой.
$ 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 не пройдет, и вам придется ввести пароль для входа.