16

Я пытаюсь настроить SSH-вход без пароля на CentOS 5.4:

  1. Я сгенерировал открытый ключ RSA на клиенте.
  2. ssh-copy-id от клиента к серверу.
  3. Проверено ~/.ssh/authorized_keys содержит ключ клиента.

Клиент по-прежнему запрашивает пароль. Что я упустил?

Благодарю.

РЕДАКТИРОВАТЬ: проверил ssh_config и разрешения, как советовали. Это отладочная информация от клиента:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.75.
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

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

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

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
saguna@192.168.1.75's password: 

10 ответов10

15

9/10 раз это потому, что ~/.ssh/authorized_keys не в правильном режиме.

chmod 600 ~/.ssh/authorized_keys
12

Зайдите в /etc /ssh /sshd_config, чтобы разрешить аутентификацию с ключом. У вас должно быть что-то вроде этого, и убедитесь, что строки не закомментированы:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

PS: не забудьте перезапустить sshd после изменения файла (/etc/init.d/sshd restart)

4

Я обнаружил, что проблема с моей системой заключалась в том, что каталог пользователя (/home/username) был неправильно настроен. Это был drwxr-x-w- и это должен был быть drwxr-xr-x (с разрешением на запись только для владельца). Решение было использовать chmod:

sudo chmod 0755 /home/username
4

Я здесь не эксперт, но тоже сталкивался с такой проблемой, вот мои два цента в дополнение ко всем другим предложениям.

Иногда ssh-copy-id копирует неправильный ключ на удаленный сервер (это может произойти, если у вас есть несколько ключей и / или вы используете нестандартные имена для файлов ключей) или ваш агент аутентификации неверно настроен.

Вот цитата из справочных страниц:

Если указана опция -i, то используется файл идентификации (по умолчанию ~/.ssh/id_rsa.pub), независимо от того, есть ли какие-либо ключи в вашем ssh-agent. В противном случае, если это: ssh-add -L предоставляет какой-либо вывод, он использует его вместо файла идентификации.

В общем, вы хотите проверить, что:

  • Ваш системный агент аутентификации (обычно ssh-agent) видит ключи, которые вы намереваетесь использовать (проверьте вывод ssh-add -L)
    • Если вы не видите нужный ключ, добавьте его с помощью ssh-add
  • ssh-copy-id скопировал этот же ключ на удаленный компьютер (просто войдите на удаленный сервер, используя пароль, и проверьте содержимое ~/.ssh/authorized_keys)
    • Если вы не видите требуемый ключ на удаленном сервере, вы можете неявно указать ssh-copy-id какой ключ копировать: ssh-copy-id -i ~/.ssh/some_public_key

Надеюсь, это поможет.

3

Наиболее распространенная проблема - неверные разрешения на стороне сервера. Убедитесь, что ни один из вашего домашнего каталога, ~/.ssh и ~/.ssh/authorized_keys не доступен для записи кому-либо, кроме вас (в частности, они не должны быть доступны для записи в группе).

Если это не проблема, запустите ssh -vvv server и посмотрите на представление клиента о диалоге . В частности, проверьте, что клиент пытается ключ с сервером.

2

В дополнение ко всему вышесказанному всегда можно проверить файл журнала sshd:

/var/log/auth.log
0

В качестве дополнения к ответу Омера Дагана для новой CentOS 7 используйте:

journalctl -f -u sshd

для просмотра логов sshd на сервере.

0

Я попробовал другие исправления, но обнаружил, что мне пришлось изменить домашний каталог, чтобы другие пользователи не могли его записать. Домашний каталог был 777. Я изменил его на 755, и это сработало.

0

в моем случае /etc /ssh /sshd_config содержал следующий параметр:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

Но ssh-copy-id создал файл с именем author_keys, поэтому мне пришлось изменить запись на новое имя. больше информации об устаревших авторизованных ключах

-1

Проблема была в том, что у меня отключена аутентификация RSA в /etc /ssh /ssh_config

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