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

Добавление открытого ключа в ~ / .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 ]

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

Вам необходимо проверить права доступа к файлу authorized_keys и папкам / родительским папкам, в которых он находится. 

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Для получения дополнительной информации см. эту страницу .

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

chmod go-w ~
143 голосов
/ 07 февраля 2014

SELinux также может привести к неработоспособности авторизованных ключей. Особенно для root в CentOS 6 и 7. Хотя отключать его не нужно. После того, как вы убедились, что ваши разрешения верны, вы можете исправить это так: 

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh
93 голосов
/ 13 июля 2014

настройка ssh authorized_keys кажется простой, но скрывает некоторые ловушки, которые я пытаюсь понять

- СЕРВЕР -

в / etc / ssh / sshd_config установить passwordAuthentication yes, чтобы разрешить серверу временно принимать аутентификацию по паролю

- КЛИЕНТ -

рассмотрите cygwin как эмуляцию linux и установите и запустите openssh

1. генерация закрытых и открытых ключей (на стороне клиента) # ssh-keygen

здесь, нажав только ENTER, вы получите DEFAULT 2 файла " id_rsa " и " id_rsa.pub " в ~ / .ssh / , но если вы предоставите name_for_the_key сгенерированные файлы сохраняются в вашем pwd

2. поместите your_key.pub на целевую машину ssh-copy-id user_name@host_name

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

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. регистрация ssh user_name@host_name будет работать только для id_rsa по умолчанию, так что здесь 2-я ловушка, вам нужно ssh -i path/to/key_name user@host

(используйте ssh -v ... , чтобы увидеть, что происходит)

Если сервер все еще запрашивает пароль , то вы дали что-то. Введите кодовую фразу: , когда вы создали ключи (это нормально)

если ssh не прослушивает порт по умолчанию 22 должен использовать ssh -p port_nr

- SERVER -----

4. изменить / etc / ssh / sshd_config , чтобы иметь 

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(uncoment, если регистр)

Это говорит ssh о том, что нужно принять санкционированные_ключи и искать в домашнем каталоге пользователя строку с именем_ключа, записанную в файле .ssh / authorized_keys

5 установка разрешений на целевом компьютере 

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Также отключите аутентификацию прохода

passwordAuthentication no

чтобы закрыть ворота для всех попыток ssh root / admin /....@ your_domain

6 обеспечить надлежащее владение и групповое владение всеми домашними каталогами без полномочий root. 

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user

===============================================

7. считают отличным http://www.fail2ban.org

8. дополнительно ssh TUNNEL для доступа к серверу MySQL (bind = 127.0.0.1)

35 голосов
/ 06 марта 2014

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

chmod g-w,o-w /home/USERNAME

Ответ украден у здесь

9 голосов
/ 30 октября 2014

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

7 голосов
/ 18 октября 2013

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

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

Перечисление открытого ключа в .ssh / authorized_keys необходимо, но недостаточно для sshd (сервера), чтобы принять его. Если ваш закрытый ключ защищен парольной фразой, вам нужно будет каждый раз давать ssh (клиент) парольную фразу. Или вы можете использовать ssh-agent или эквивалент гнома.

Ваша трассировка UPDATE соответствует закрытому ключу, защищенному парольной фразой. См. Ssh-agent или ssh-keygen -p.

6 голосов
/ 14 ноября 2015

пользователь - ваше имя пользователя 

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts
5 голосов
/ 08 ноября 2014

Наконец, мне удалось добиться того, чтобы владелец / группа были не пользователем root, а пользователем: 

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user
4 голосов
/ 13 марта 2014

Запись команды: 

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

После того, как вы сделаете это, убедитесь, что ваш каталог такой: 

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub
Страница:
...