Попытка настроить SSH для моего CentOS VPS с ключом аутентификации и без пароля, чтобы я мог автоматически подключиться с моего локального сервера Debian 7. Я дошел до того, что копировал и вставлял из двух разных руководств в сети (здесь и здесь), и меня все еще спрашивают о пароле. (не парольная фраза)

Мой удаленный раздел аутентификации sshd_config, отрезанный прямо перед разделом kerberos:

    # Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile ~/.ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

Remote /var /log /secure не содержит ошибок:

Jun 13 07:02:14 *remote host* sshd[4206]: Accepted password for admin from *my-ip* port 48919 ssh2
Jun 13 07:02:15 *remote host* sshd[4206]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Jun 13 07:02:20 *remote host* sshd[4220]: Received disconnect from *my-ip*: 11: disconnected by user
Jun 13 07:02:20 *remote host* sshd[4206]: pam_unix(sshd:session): session closed for user admin

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

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: *local/user/home*/.ssh/id_rsa ((nil))
debug2: key: *local/user/home*/.ssh/id_dsa ((nil))
debug2: key: *local/user/home*/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: *local/user/home*/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: *local/user/home*/.ssh/id_dsa
debug1: Trying private key: *local/user/home*/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
admin@*remote server*'s password:

После прочтения предложений и следуя второму руководству, я попытался установить и 755, и 600 для всего в локальных и удаленных каталогах ~/ .ssh/, и это все еще не работает. Как я уже сказал, я скопировал и вставил эту команду:

cat id_rsa.pub >> authorized_keys

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

Есть идеи?

|источник

5 ответов5

1

У вас неверное значение для параметра AuthorizedKeysFile. От человека sshd_config:

AuthorizedKeysFile может содержать токены в форме% T, которые подставляются во время установки соединения. Определены следующие токены: %% заменяется литералом '%',% h заменяется домашним каталогом аутентифицируемого пользователя, а% u заменяется именем пользователя этого пользователя. После расширения AuthorizedKeysFile считается абсолютным или относительным путем к домашнему каталогу пользователя. По умолчанию используется ".ssh/ авторизованный_кей".

|источник
1

Другое решение для SELinux, которое не позволяет sshd читать $ HOME/.ssh, - это использовать restorecon, см. Мой ответ здесь https://superuser.com/a/764020/213743.

|источник
1

Спасибо всем за помощь. Я полагаю, вам всем не понравится слышать, что это просто волшебным образом исправило себя сегодня. Правильно: я проснулся, установил на VPS какое-то другое программное обеспечение (некоторые вещи, связанные с irssi), перезагрузился (хотя я пробовал это прошлой ночью вместе с перезагрузкой службы sshd), вошел в SSH, чтобы попробовать некоторые предложения , и это дало мне новое WARNING: UNPROTECTED PRIVATE KEY FILE! сообщение. Поскольку в последнее время я выполнял chmod -R 755 .ssh/ для своих локальных файлов SSH, потому что 600 по какой-то странной причине не позволяет ему выдать ключ, я использовал chmod -R 700 .ssh/ после этого предупреждения, и теперь все работает хорошо. Я действительно не знаю, что случилось. Еще раз спасибо всем за уделенное время.

|источник
0

Еще одна вещь, которая может привести к тому, что we did not send a packet, disable method , если сервер настроен на отклонение вашего входа в систему. Например, если вы попытаетесь войти в систему как пользователь root когда в конфигурации содержится PermitRootLogin no .

|источник
0

Если в системе есть SELinux, отредактируйте /etc/selinux/config и измените 

SELINUX=enforcing

в

SELINUX=permissive
|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .