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

446

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

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

user482594
источник
5
Хотя в данном случае это не так, если вы используете Google и используете зашифрованный домашний каталог, sshd не сможет получить к нему доступ и, следовательно, не сможет прочитать ваш файл author_keys. Вот решение: bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/…
Даниэль Шаффер

Ответы:

1097

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

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

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

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

chmod go-w ~
Тедди
источник
6
Что-то из вышеперечисленного сработало, хотя разве "chmod -R go-wrx foobar" довольно драматично? Почему нужно рекурсивное?
Иоахим
9
Во второй части не обязательно делать это рекурсивным, достаточно просто выполнить chmod go-wrx foobar. Выполнение этого рекурсивно может серьезно осложнить работу некоторых приложений, если у вас есть какой-то групповой или иной доступ к файлам, особенно если это веб-каталог.
StingeyB
24
Как упоминалось в FAQ по OpenSSH, домашнему каталогу & .ssh пользователя нужно только удалить разрешение на запись для группы / другого (так и chmod go-w $HOME $HOME/.sshбудет сделано). Таким образом, разрешения могут быть такими же «открытыми», как 755 для обоих каталогов, если вы так склонны. Простейшие / наименее инвазивные команды находятся в FAQ: openssh.org/faq.html#3.14
davidjb
3
Почему это не сработало для меня, пока я не сработал chmod 700 ~/.ssh && chmod 644 ~/.ssh/authorized_keys? 600 не сработало там, где 644 ...
ficuscr
3
Мне также нужно было, sudo chown -R {$USER}:{$USER} ~/.ssh/потому что я написал authorized_keysфайл как root.
Зейн Хупер
155

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

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh
Коул Стэнфилд
источник
7
Это restoreconто, что вам нужно после того, как вы скопировали файлы вручную, например, на новый жесткий диск. (В этом случае вам, вероятно, следует запустить его на всех файлах. Это может исправить другие странные проблемы.)
ospalh
Еще один счастливый турист здесь. Это была моя проблема в RHEL 6.5
Антонио Ортелс
2
9/10 раз проблема «почему это не работает, это всегда работает» - это проблема selinux.
Эндрю Уайт
исправил проблему для меня на сервере 1and1 (1und1)
musicman
104

настройка 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)

bortunac
источник
5
Обратите внимание, что «только 4 безопасности» не только для безопасности! SSH будет игнорировать файл, если у него нет ограничительных разрешений.
Навин
Обеспечение права собственности было бы отличным дополнением к этому списку
Steviejay
1
Я понятия не имел о ssh-copy-id! Один этот шаг мог бы стать отличным ответом.
Джеймс Мрамор
1
chmod 755 ~ / .ssh вместо 700, который я вижу в другом месте, казалось, делал это
Джим В. говорит восстановить Monica
36

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

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

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

Стефан Хойер
источник
4
Делать chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; chmod g-w,o-w ~работал для меня. Спасибо.
gbraad
1
почему бы не использовать только chmod og-w /home/USERNAMEвместо этого?
Парамвир Сингх Карвал
13

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

Александр Тейлор
источник
2
Это именно то, что случилось со мной! Два терминала имеют одинаковую ширину, поэтому сложно понять, пока я не включу номера строк, чтобы увидеть две строки в файле author_keys.
Шон
1
Эта. Я просто потратил час из-за этого. И это не первый раз. В ответе @ bortunac упоминается инструмент ssh-copy-id, который я буду использовать в будущем, чтобы избежать этого.
xdhmoore
Я получил содержание id_rsa.pubиспользования moreвместо cat, что было фатальным из-за невидимых разрывов строк.
Дэн Халберт
8

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

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
wcc526
источник
Лучше для рута:mkdir -p /home/$USER/.ssh && chown -R $USER:$USER /home/$USER/.ssh && sudo -u $USER ssh-keygen -t rsa && touch /home/$USER/.ssh/authorized_keys && touch /home/$USER/.ssh/known_hosts && 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 && vim /home/$USER/.ssh/authorized_keys # paste keys here!
Одиссей
7

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

Nim
источник
Вы можете видеть вмешательство SELinux /var/log/audit/audit.log. restorecon -R -v /root/.sshисправил мой конкретный случай.
Дейв Гуделл
7

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

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

fche
источник
5

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

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
Exsonic
источник
1
Чем ваш ответ отличается от принятого? Вы написали это 3 года спустя, используя команду Ctrl + C Ctrl-V?
жало
5

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

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 
Ulliroyal
источник
chown: недопустимый пользователь: '/home/lsa/.ssh/'
Степан Яковенко
3

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

H99
источник
3

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

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

user2683246
источник
3

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

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

Шон Баннистер
источник
Существует целый класс проблем, которые могут возникнуть на сервере (при попытке подключения с клиента), которые невозможно отладить без доступа к серверу ... Это сделано для того, чтобы скрыть информацию от вредоносных клиентов, но затрудняет отладки.
Qneill
2

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

Джордж
источник
2

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

ssh-agent bash

SSH-добавить

юлианский
источник
Объясните, что это делает, пожалуйста.
любослав канев
Ssh-agent хранит ваши ключи ssh .. команда bash запускает новый экземпляр своей оболочки. и ssh-add разблокирует ваши ключи и загрузит их
Julian
2

Еще одна проблема, которую вы должны решить. Если ваш сгенерированный файл не по умолчанию 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
Kunthar
источник
2
IdentityFile должен быть закрытым ключом
Кен Х
@KenH да, конечно. опечатка это. простите за это.
Кунтар
1

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

GJSmith3rd
источник
1

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

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

детеныш
источник
3
Это выглядит практически идентично принятому ответу и, вероятно, должно было быть комментарием, а не ответом. С чуть большим количеством представителей вы сможете оставлять комментарии . До тех пор, пожалуйста, не используйте ответы в качестве обходного пути.
Натан Тагги
Извините, я подумал, что это способ решить все эти вопросы. Теперь я знаю, как это сделать сейчас, спасибо.
Джои
1

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

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u
отметка
источник
1

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

Эдвард ван Куйк
источник
1

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

Willem
источник
2
использовал ssh-copy-id
вишну
1

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

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub
манна
источник
1

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

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

PermitRootLogin without-password

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

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

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

PermitRootLogin no
Эдд Стэнс
источник
0

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

pppk520
источник
0

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

alexandrul
источник
0

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

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

chown root.root /root
chmod 700 /root

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

Джейсон Коэн
источник
0

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

бувигер
источник