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

Ответ 1

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

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

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

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

chmod go-w ~

Ответ 2

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

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

Ответ 3

настройка 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 [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..., чтобы увидеть, что происходит)

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

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

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

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

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

(несовестный случай)

Это говорит ssh принимать authorized_keys и искать в домашнем каталоге пользователя для sting key_name, записанного в файле .ssh/authorized_keys

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

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

Также выключите pass auth

passwordAuthentication no

закрыть ворота ко всем попыткам ssh root/admin/[email protected]_domain

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

Команда записи:

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

Еще одна проблема, которую вы должны позаботиться. Если ваш сгенерированный файл не является стандартным 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

Ответ 16

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

Ответ 17

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

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

Ответ 18

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

ssh-agent bash

     

SSH-добавить

Ответ 19

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

Ответ 20

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

Ответ 21

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

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

Ответ 22

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

PermitRootLogin without-password

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

и повторите попытку входа в систему!

По умолчанию я верю -

PermitRootLogin no

Ответ 23

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

Ответ 24

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

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

Ответ 25

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

Ответ 26

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

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

chown root.root /root
chmod 700 /root

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

Ответ 27

Посмотрите на /var/log/auth.log на сервере ошибки sshd auth.

Если ничего не помогает, запустите сервер 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

Ответ 28

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