Добавление открытого ключа в ~ / .ssh / authorized_keys не приводит к автоматическому входу в систему - PullRequest
Новая
       95

Добавление открытого ключа в ~ / .ssh / authorized_keys не приводит к автоматическому входу в систему

403 голосов
/ 16 июня 2011

Я добавил публичный ключ ssh в файл author_keys. ssh localhost должен войти в систему, не спрашивая пароль.

Я сделал это и попытался набрать ssh localhost, но он все равно просит меня ввести пароль. Есть ли какие-либо другие настройки, через которые мне нужно пройти, чтобы заставить их работать?

Я следовал инструкции по изменению разрешений:

Ниже приведен результат, если я сделаю ssh -v localhost

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Затем он запрашивает пароль после вышеуказанного журнала. Почему он не регистрирует меня без пароля?

Ответы [ 28 ]

1 голос
/ 09 января 2018

Убедитесь, что вы скопировали весь открытый ключ в authorized_keys; для работы ключа необходим префикс ssh rsa.

0 голосов
/ 27 мая 2019

У меня была эта проблема, когда я добавил группу логина другому пользователю. Допустим, есть пользователь ssh-login с именем userA и пользователь user-не-ssh-loginB. У userA также есть группа userA. Я изменил userB, чтобы иметь также группу userA. Это привело к описанному поведению, так что пользователь A не смог войти без приглашения. После того как я удалил группу userA из userB, вход в систему без приглашения снова заработал.

0 голосов
/ 22 октября 2018

Посмотрите на /var/log/auth.log на сервере для sshd ошибок аутентификации.

Если ничего не помогает, запустите сервер sshd в режиме отладки: 

sudo /usr/sbin/sshd -ddd -p 2200

Затем подключитесь с клиента: 

ssh user@host -p 2200

В моем случае я нашел раздел об ошибке в конце: 

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Получив эту информацию, я понял, что мой sshd_config ограничивал вход в систему членам группы ssh. Следующая команда исправила эту ошибку разрешения: 

sudo usermod -a -G ssh NEW_USER
0 голосов
/ 02 сентября 2018

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

В моем случае оказалось, что сам каталог /root(не например /root/.ssh) имели неправильные разрешения.Мне нужно было: 

chown root.root /root
chmod 700 /root

Конечно, эти разрешения должны быть примерно такими (возможно chmod 770) независимо от этого.Тем не менее, это определенно препятствовало работе sshd, хотя /root/.ssh и /root/.ssh/authorized_keys имели правильные разрешения и владельцев.

0 голосов
/ 03 февраля 2015

на этой заметке, убедитесь, что в конфигурации sshd -; 

PermitRootLogin without-password

, как указано выше, затем перезапустите sshd (/etc/init.d/sshd restart)

logи попробуйте снова войти в систему!

по умолчанию я считаю -; 

PermitRootLogin no
0 голосов
/ 26 января 2016

В моем случае это потому, что группа пользователей не задана в AllowGroups файла конфигурации / etc / ssh / sshd_config.После добавления все работает нормально.

0 голосов
/ 25 ноября 2016

У меня есть домашний каталог в нестандартном месте и в sshd журналах. У меня есть эта строка: 

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

, даже если все разрешения были в порядке (см. Другие ответы).

Я нашел решение здесь: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

В моем конкретном случае:

  • добавил новую строку в /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

    • это оригинальная строка для обычных домашних каталогов:

      /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

    • это моя новая строка:

      /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • с последующим restorecon -r /data/ и sshd перезапуском

0 голосов
/ 28 марта 2016

Моей проблемой был измененный AuthorizedKeysFile, когда автоматизация для заполнения / etc / ssh / authorized_keys еще не была запущена. 

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u
Страница:
...