it-swarm.com.ru

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

Я добавил публичный ключ 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>

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

378
user482594

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

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

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

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

chmod go-w ~
953
Teddy

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

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

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

- СЕРВЕР -

в / 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 [email protected]_name

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

ssh-copy-id -i path/to/key_name.pub [email protected]_name

3. logging ssh [email protected]_name будет работать только для id_rsa по умолчанию, так что здесь 2-ая ловушка, вам нужно ssh -i path/to/key_name [email protected]

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

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

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

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

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 /[email protected] your_domain

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

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

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

7. считают превосходным http://www.fail2ban.org

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

90
bortunac

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

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

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

34
Stephan Hoyer

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

9
Alexander Taylor

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

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

7
fche

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

7
Nim

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

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
wcc526

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

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 
4
Ulrich Behrendt

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

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

3
Sean Bannister

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

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
3
Exsonic

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

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

3
user2683246

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

3
h99

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

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

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

Host remote_Host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub
2
Kunthar

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

2
George

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

1
Willem

вам нужно проверить свойства файлов . чтобы назначить требуемое свойство, используйте:

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

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

ssh-agent bash

sSH-добавить

1
Julian

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

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

1
Joey

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

1
GJSmith3rd

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

0
Edward van Kuik

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

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

PermitRootLogin without-password

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

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

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

PermitRootLogin no
0
Edd Stance

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

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

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

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

ssh [email protected] -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
cmcginty

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

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

chown root.root /root
chmod 700 /root

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

0
Jason Cohen

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

0
Bevor

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

$Sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u
0
Mark

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

0
pppk520