Я добавил открытый ключ 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>
Затем он запрашивает фазу после вышеуказанного журнала. Почему он не входит в систему без пароля?
ssh
public-key
authorized-keys
user482594
источник
источник
Ответы:
Вам необходимо проверить права доступа к
authorized_keys
файлу и папкам / родительским папкам, в которых он находится.Для получения дополнительной информации см. Эту страницу .
Вам также может понадобиться изменить / проверить разрешения вашего домашнего каталога, чтобы удалить права на запись для группы и других пользователей.
источник
chmod go-wrx foobar
. Выполнение этого рекурсивно может серьезно осложнить работу некоторых приложений, если у вас есть какой-то групповой или иной доступ к файлам, особенно если это веб-каталог.chmod go-w $HOME $HOME/.ssh
будет сделано). Таким образом, разрешения могут быть такими же «открытыми», как 755 для обоих каталогов, если вы так склонны. Простейшие / наименее инвазивные команды находятся в FAQ: openssh.org/faq.html#3.14chmod 700 ~/.ssh && chmod 644 ~/.ssh/authorized_keys
? 600 не сработало там, где 644 ...sudo chown -R {$USER}:{$USER} ~/.ssh/
потому что я написалauthorized_keys
файл как root.SELinux также может привести к неработоспособности авторизованных ключей. Особенно для root в CentOS 6 и 7. Хотя отключать его не нужно. После того, как вы убедились, что ваши разрешения верны, вы можете исправить это так:
источник
restorecon
то, что вам нужно после того, как вы скопировали файлы вручную, например, на новый жесткий диск. (В этом случае вам, вероятно, следует запустить его на всех файлах. Это может исправить другие странные проблемы.)настройка SSH авторизованных ключей кажется простой, но скрывает некоторые ловушки, которые я пытаюсь понять
- СЕРВЕР -
в / / SSH / sshd_config и т.д. установить ,
passwordAuthentication yes
чтобы сервер временно принимает пароль аутентификации- КЛИЕНТ -
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, чтобы иметь
(uncoment если дело)
Это говорит ssh о том, что нужно принять author_keys и искать в домашнем каталоге пользователя строку с именем ключа, записанную в файле .ssh / authorized_keys.
5 установленных разрешений в целевой машине
Также отключите проход аутентификации
passwordAuthentication no
закрыть ворота для всех попыток ssh root / admin /....@ your_domain
6 убедитесь, что владение и групповое владение всеми некорневыми домашними каталогами являются соответствующими.
===============================================
7. рассмотреть отличные http://www.fail2ban.org
8. дополнительный ssh TUNNEL для доступа к серверу MySQL (bind = 127.0.0.1)
источник
ssh-copy-id
! Один этот шаг мог бы стать отличным ответом.Также убедитесь, что ваш домашний каталог не доступен для записи другим
Ответ украден отсюда
источник
chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; chmod g-w,o-w ~
работал для меня. Спасибо.chmod og-w /home/USERNAME
вместо этого?отчаявшиеся также могут убедиться, что у них нет лишних строк новой строки в файле author_keys из-за копирования текста id_rsa.pub из перепутанного терминала.
источник
id_rsa.pub
использованияmore
вместоcat
, что было фатальным из-за невидимых разрывов строк.пользователь ваше имя пользователя
источник
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!
Помните, что SELinux также может вызвать эту ошибку, даже если все разрешения в порядке. Отключение этой функции помогло мне (вставьте обычные уведомления об отключении).
источник
/var/log/audit/audit.log
.restorecon -R -v /root/.ssh
исправил мой конкретный случай.Перечисление открытого ключа в .ssh / authorized_keys необходимо, но не достаточно для sshd (сервера), чтобы принять его. Если ваш закрытый ключ защищен парольной фразой, вам нужно будет каждый раз давать ssh (клиент) парольную фразу. Или вы можете использовать ssh-agent или эквивалент GNOME.
Ваш обновленный след согласуется с закрытым ключом парольной фразы защищенным. Смотрите ssh-agent или используйте
ssh-keygen -p
.источник
Написать команду:
После этого убедитесь, что ваш каталог такой:
источник
Наконец, мне удалось добиться того, чтобы владелец / группа были не пользователем root, а пользователем:
источник
Попробуйте "ssh-add", который работал для меня.
источник
Еще один совет, чтобы помнить. Поскольку v7.0 OpenSSH по умолчанию отключает ssh-ключи DSS / DSA из-за их слабости наследования. Так что если у вас OpenSSH v7.0 +, убедитесь, что ваш ключ не
ssh-dss
.источник
В моем случае мне нужно было положить мой
authorized_keys
файл в.openssh
.Это место указано в
/etc/ssh/sshd_config
опцииAuthorizedKeysFile %h/.ssh/authorized_keys
.источник
Убедитесь, что у целевого пользователя установлен пароль. Беги,
passwd username
чтобы установить один. Это было необходимо для меня, даже если пароль SSH логин был отключен.источник
это решает мою проблему
источник
Еще одна проблема, которую вы должны решить. Если ваш сгенерированный файл не по умолчанию
id_rsa
иid_rsa.pub
Вы должны создать файл .ssh / config и вручную определить, какой файл id вы собираетесь использовать с соединением.
Пример здесь:
источник
Я издал
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 еще не была запущена.
источник
Просто посмотрите на /var/log/auth.log на сервере . Установка дополнительной детализации с помощью -vv на стороне клиента не поможет, поскольку сервер вряд ли предложит слишком много информации возможному злоумышленнику.
источник
Убедитесь, что вы скопировали весь открытый ключ
authorized_keys
;ssh rsa
префикс необходим для ключа к работе.источник
вам нужно проверить свойства файлов. для назначения необходимого свойства используйте:
источник
Посмотрите на
/var/log/auth.log
сервереsshd
ошибки аутентификации.Если ничего не помогает, запустите
sshd
сервер в режиме отладки:Затем подключитесь с клиента:
В моем случае я нашел раздел об ошибке в конце:
Получив эту информацию, я понял, что мой
sshd_config
ограничивает вход в систему для членовssh
группы. Следующая команда исправила эту ошибку разрешения:источник
на этой ноте убедитесь, что в вашем sshd config есть -;
установите как указано выше, затем перезапустите sshd (/etc/init.d/sshd restart)
Выйдите из системы и попробуйте войти снова!
по умолчанию я считаю, -;
источник
В моем случае это потому, что группа пользователей не установлена в AllowGroups файла конфигурации / etc / ssh / sshd_config. После добавления все работает нормально.
источник
У меня есть домашний каталог в нестандартном месте, и в
sshd
логах у меня есть эта строка:даже если все разрешения были просто в порядке (см. другие ответы).
Я нашел решение здесь: 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
) имел неправильные разрешения. Мне было нужно:Конечно, эти разрешения должны быть примерно такими (возможно
chmod 770
) независимо от этого. Тем не менее, он определенно мешалsshd
работать, хотя/root/.ssh
и/root/.ssh/authorized_keys
оба имели правильные разрешения и владельцев.источник
У меня возникла эта проблема, когда я добавил группу логина другому пользователю. Допустим, есть пользователь ssh-login с именем userA и пользователь user-не-ssh-loginB. У userA также есть группа userA. Я изменил userB, чтобы иметь также группу userA. Это привело к описанному поведению, так что пользователь A не смог войти без приглашения. После того как я удалил группу userA из userB, вход в систему без приглашения снова заработал.
источник