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

Я добавил открытый ключ SSH к authorized_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>

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

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

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

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

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

chmod go-w ~

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

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

настройка SSH авторизованных ключей кажется простой, но скрывает некоторые ловушки, которые я пытаюсь понять

- СЕРВЕР -

в / / 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

- СЕРВЕР -----

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

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

(uncoment если дело)

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

5 установленных разрешений в целевой машине

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

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

passwordAuthentication no

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

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

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

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

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

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

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

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

Ответ украден отсюда

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

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

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

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

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

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

Написать команду:

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

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

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

Попробуйте "ssh-add", который работал для меня.

Еще один совет, чтобы помнить. Поскольку v7.0 OpenSSH по умолчанию отключает ssh-ключи DSS / DSA из-за их слабости наследования. Так что если у вас OpenSSH v7.0 +, убедитесь, что ваш ключ не ssh-dss.

Если вы застряли с ключами DSA, вы можете снова включить поддержку локально, обновив свои файлы sshd_configи ~/.ssh/configфайлы такими строками:PubkeyAcceptedKeyTypes=+ssh-dss

В моем случае мне нужно было положить мой authorized_keysфайл в .openssh.

Это место указано в /etc/ssh/sshd_configопции AuthorizedKeysFile %h/.ssh/authorized_keys.

Убедитесь, что у целевого пользователя установлен пароль. Беги, passwd usernameчтобы установить один. Это было необходимо для меня, даже если пароль SSH логин был отключен.

это решает мою проблему

ssh-agent bash

SSH-добавить

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

Вы должны создать файл .ssh / config и вручную определить, какой файл id вы собираетесь использовать с соединением.

Пример здесь:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

Я издал sudo chmod 700 ~/.sshи chmod 600 ~/.ssh/authorized_keysи chmod go-w $HOME $HOME/.sshсверху , и это фиксированная моя проблема на коробке CentOS7 , что я испортил разрешения на при попытке получить самбы акции работают. Спасибо

Это похоже на проблему с разрешением. Обычно это происходит, если разрешение какого-либо файла / каталога установлено неправильно. В большинстве случаев они есть ~/.sshи ~/.ssh/*. В моем случае они есть /home/xxx.

Вы можете изменить уровень журнала sshd, изменив /etc/ssh/sshd_config(поиск LogLevel, установите его DEBUG), а затем проверьте вывод, /var/log/auth.logчтобы увидеть, что именно произошло.

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

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Просто посмотрите на /var/log/auth.log на сервере . Установка дополнительной детализации с помощью -vv на стороне клиента не поможет, поскольку сервер вряд ли предложит слишком много информации возможному злоумышленнику.

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

вам нужно проверить свойства файлов. для назначения необходимого свойства используйте:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

Посмотрите на /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

на этой ноте убедитесь, что в вашем sshd config есть -;

PermitRootLogin without-password

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

Выйдите из системы и попробуйте войти снова!

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

PermitRootLogin no

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

У меня есть домашний каталог в нестандартном месте, и в 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перезагрузкой

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

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

chown root.root /root
chmod 700 /root

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

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