Почему я все еще получаю приглашение пароля с помощью ssh с аутентификацией с открытым ключом?

Я работаю с URL-адресом, который я нашел здесь:

353 голоса | спросил Thom 16 PMpMon, 16 Apr 2012 18:38:49 +040038Monday 2012, 18:38:49

23 ответа


444

Убедитесь, что права на каталог ~/.ssh и его содержимое являются правильными. Когда я впервые установил свой ssh ​​key auth, у меня не было правильно настроенной папки ~/.ssh, и она закричала на меня.

  • Ваш домашний каталог ~, ваш каталог ~/.ssh и файл ~/.ssh/authorized_keys на удаленной машине должны быть доступен только вам: rwx------ и rwxr-xr-x все в порядке, но rwxrwx--- не подходит. , даже если вы единственный пользователь в своей группе (если вы предпочитаете числовые режимы: 700 или 755, а не 775).
    Если ~/.ssh или authorized_keys является символической ссылкой, отмечен канонический путь (с расширением символьных ссылок) .
  • Ваш файл ~/.ssh/authorized_keys (на удаленном компьютере) должен быть доступен для чтения (не менее 400), но вам потребуется его перезаписывать (600), если вы добавите больше ключей к нему.
  • Ваш файл закрытого ключа (на локальном компьютере) должен быть доступен для чтения и записи только вам: rw-------, т.е. 600.
  • Кроме того, если SELinux настроен на принудительное выполнение, вам может потребоваться запустить restorecon -R -v ~/.ssh (см., например, ошибка Ubuntu 965663 и Отчет об ошибке в Debian # 658675 , это исправленный в CentOS 6 ).

¹¹ За исключением некоторых дистрибутивов (Debian и производных), которые исправили код, чтобы разрешить возможность записи на группы, если вы единственный пользователь в своей группе. Суб>

ответил Rob 17 PMpTue, 17 Apr 2012 19:28:54 +040028Tuesday 2012, 19:28:54
122

Если у вас есть root-доступ к серверу, простой способ решить такие проблемы - запустить sshd в режиме отладки, выпустив что-то вроде /usr/sbin/sshd -d -p 2222 на сервер (полный путь к исполняемому исполняемому файлу sshd, which sshd), а затем соединение с клиентом с помощью ssh -p 2222 [email protected]. Это заставит демон SSH оставаться на переднем плане и отображать отладочную информацию о каждом соединении. Найдите что-то вроде

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Если использовать альтернативный порт невозможно, вы можете временно остановить демон SSH и заменить его на один в режиме отладки. Остановка SSH-демона не убивает существующие соединения, поэтому можно сделать это через удаленный терминал, но несколько рискованно - если соединение каким-то образом сломается в то время, когда замена отладки не запущена, вы заблокированы из машины пока вы не сможете его перезапустить. Необходимые команды:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start
ответил Tgr 12 12012vEurope/Moscow11bEurope/MoscowMon, 12 Nov 2012 11:55:52 +0400 2012, 11:55:52
47

Зашифрован ли ваш домашний компьютер? Если это так, для вашей первой сессии ssh вам нужно будет предоставить пароль. Второй сеанс ssh на том же сервере работает с ключом auth. Если это так, вы можете переместить свой authorized_keys в незашифрованный каталог и изменить путь в ~/.ssh/config.

В результате я создал папку /etc/ssh/username, принадлежащую имени пользователя, с правильными разрешениями и разместил там файл authorized_keys. Затем изменили директиву AuthorizedKeysFile в /etc/ssh/config на:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Это позволяет нескольким пользователям иметь этот доступ ssh без компрометации разрешений.

ответил cee 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 23 Sep 2012 13:31:28 +0400 2012, 13:31:28
24

Просто попробуйте следующие команды

  1. ssh-keygen

    Нажмите клавишу «Ввод», пока не получите приглашение

  2. ssh-copy-id -i [email protected]_address

    (Он будет запрашивать пароль хост-системы)

  3. ssh [email protected]_address

    Теперь вы можете войти в систему без пароля

ответил Ravindra 17 Maypm13 2013, 12:46:32
24

После копирования ключей на удаленный компьютер и помещения их в authorized_keys вам нужно сделать что-то вроде этого:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
ответил gusior 7 42013vEurope/Moscow11bEurope/MoscowThu, 07 Nov 2013 04:16:46 +0400 2013, 04:16:46
20

Я столкнулся с проблемами, когда домашний каталог на удаленном компьютере не имеет правильных привилегий. В моем случае пользователь изменил домашний каталог на 777 для локального доступа в команде. Аппарат больше не мог соединиться с ключами ssh. Я изменил разрешение на 744 , и он снова начал работать.

ответил Sahil 3 J000000Tuesday12 2012, 11:34:33
11

SELinux на RedHat /CentOS 6 имеет проблему с аутентификацией pubkey , возможно, когда некоторые из файлов создаются selinux не устанавливает свои ACL правильно.

Чтобы вручную установить ACL для SElinux для пользователя root:

restorecon -R -v /root/.ssh
ответил David Mackintosh 8 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 08 Sep 2014 22:44:05 +0400 2014, 22:44:05
10

Мы столкнулись с той же проблемой, и мы выполнили шаги в ответе. Но это все еще не сработало для нас. Наша проблема заключалась в том, что логин работал от одного клиента, но не от другого (каталог .ssh был установлен NFS, и оба клиента использовали одни и те же ключи).

Итак, нам нужно было сделать еще один шаг вперед. Запустив команду ssh в подробном режиме, вы получите много информации.

ssh -vv [email protected]

Мы обнаружили, что ключ по умолчанию (id_rsa) не был принят, и вместо этого клиент ssh предложил ключ, соответствующий имени хоста клиента:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: [email protected]                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Очевидно, что это не сработает ни с каким другим клиентом.

Таким образом, решение в нашем случае состояло в том, чтобы переключить ключ rsa по умолчанию на тот, который содержит user @ myclient. Когда ключ по умолчанию, проверка имени клиента отсутствует.

Затем мы столкнулись с другой проблемой после переключения. По-видимому, ключи кэшируются в локальном агенте ssh, и мы получили следующую ошибку в журнале отладки:

'Agent admitted failure to sign using the key'

Это было решено перезагрузкой ключей агенту ssh:

ssh-add
ответил Joachim Nilsson 6 42014vEurope/Moscow11bEurope/MoscowThu, 06 Nov 2014 12:34:56 +0300 2014, 12:34:56
6

Это будет SSH пропустить конфигурацию на сервере. Файл sshd_config на стороне сервера должен быть отредактирован. Расположен в /etc/ssh/sshd_config. В этом файле изменить переменные

  • 'yes' to 'no' для ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

  • 'no' to 'yes' для PubkeyAuthentication

На основе http: //kaotickreation .com /2008/05/21 /отключить-SSH-пароль-аутентификации для добавленной безопасности /

ответил nish 3 J0000006Europe/Moscow 2014, 14:13:42
5

Убедитесь, что AuthorizedKeysFile указывает на нужное место, используйте %u в качестве заполнителя для имени пользователя:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Возможно, вам просто нужно раскомментировать строку:

AuthorizedKeysFile .ssh /authorized_keys

Помните, что вы должны перезагрузить службу ssh для следующих изменений:

service sshd reload
ответил Dziamid 1 J000000Monday13 2013, 19:41:07
3

Два комментария: это перезапишет исходный файл. Я бы просто скопировал открытый открытый ключ и сделал что-то вроде:

cat your_public_key.pub >> .ssh/authorized_keys

Это добавит ключ, который вы хотите использовать, в уже существующий список ключей. Кроме того, некоторые системы используют файл authorized_keys2, поэтому рекомендуется направить жесткую ссылку между authorized_keys и authorized_keys2, на всякий случай.

ответил Wojtek Rzepala 16 PMpMon, 16 Apr 2012 18:44:13 +040044Monday 2012, 18:44:13
3

В файле /etc /selinux /config, с помощью которого SELINUX отключается от принудительного выполнения сделанного без пароля ssh, успешно работает.

Раньше я могу сделать это одним способом. Теперь из обоих путей я могу сделать без пароля ssh.

ответил chinna 10 PMpWed, 10 Apr 2013 14:09:17 +040009Wednesday 2013, 14:09:17
3

Мое решение состояло в том, что учетная запись была заблокирована. Сообщение найдено в /var /log /secure: Пользователь не разрешен, поскольку учетная запись заблокирована Решение: дайте пользователю новый пароль.

ответил user46932 11 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 11 Sep 2013 18:29:43 +0400 2013, 18:29:43
3

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

/usr/sbin/sshd -d

Это показало следующий результат:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

Это было действительно запутанно

[[email protected] ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

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

[[email protected] ~]# chmod 750 /root

Ключ аутентификации начал работать.

ответил Jagadish 16 TueEurope/Moscow2014-12-16T13:44:10+03:00Europe/Moscow12bEurope/MoscowTue, 16 Dec 2014 13:44:10 +0300 2014, 13:44:10
1

Эти шаги должны помочь вам. Я использую это регулярно среди многих 64-битных машин Ubuntu 10.04.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

вы можете поместить это в скрипт с некоторыми приглашениями и вызвать его как

script_name username remote_machine
ответил Sriharsha 17 AMpTue, 17 Apr 2012 08:38:22 +040038Tuesday 2012, 08:38:22
1

У меня была аналогичная проблема с ssh. В моем случае проблема заключалась в том, что я установил hasoop cloudera (от rpm на centos 6) и создал пользовательские hdfs с домашним каталогом

/var/lib/hadoop-hdfs (не стандартный /home/hdfs).

Я изменил в /etc /passwd /var/lib/hadoop-hdfs на /home/hdfs, переместил домашний каталог в новое место, и теперь я могу подключиться к аутентификация с открытым ключом.

ответил Andrzej Jozwik 9 Jpm1000000pmThu, 09 Jan 2014 17:28:34 +040014 2014, 17:28:34
1

Одна вещь, в которой я ошибалась, - это право собственности на мой домашний каталог на серверной системе. Система сервера была установлена ​​по умолчанию: по умолчанию, так что I:

chown -R root:root /root

И это сработало. Еще одно дешевое обходное решение - отключить StrictModes: StirctModes no. в sshd_config. Это, по крайней мере, скажет вам, хороши ли обмен ключами и протоколы соединения. Затем вы можете искать хорошие разрешения.

ответил Will 3 J0000006Europe/Moscow 2014, 22:36:21
1

Для меня решение было противоположным Wojtek Rzepala's : я не заметил, что все еще использовал authorized_keys2, который устарел . Моя настройка ssh перестала работать в какой-то момент, предположительно, когда сервер был обновлен. Переименование .ssh/authorized_keys2 в качестве .ssh/authorized_keys устраняет проблему.

D'о!

ответил Michael Scheper 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 30 Sep 2014 05:33:13 +0400 2014, 05:33:13
1

У меня была такая же проблема, и для меня решение заключалось в том, чтобы установить UsePAM на no. Смотрите, даже если PasswordAuthentication установлен в no, вы все равно получите keyboard-interactive, и в моем случае моя локальная ssh-программа продолжала дефолтировать что по какой-то причине.

Дополнительный фон, чтобы помочь кому-либо с одинаковой ситуацией: я подключаюсь к хосту, работающему с Dropbear, к одному запущенному OpenSSH. С помощью PasswordAuthentication и UsePAM оба установили no на удаленном компьютере, я получу следующее сообщение, если я введу ssh [email protected]:

ssh: Connection to [email protected]:22 exited: Disconnect received

Предоставление файла с идентификатором -i, все работает так, как ожидалось.

Здесь может быть немного больше информации .

ответил Marty 31 +03002014-10-31T22:08:52+03:00312014bEurope/MoscowFri, 31 Oct 2014 22:08:52 +0300 2014, 22:08:52
1

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

Команды сервера:

# rm -rf ~/.ssh

Локальные команды:

# ssh-copy-id [email protected]        # where <user> is your username and <192.168.1.1> is the server IP
ответил Steven C. Howell 6 Maypm16 2016, 22:27:45
1

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

  1. ОТ КЛИЕНТА - Генерировать ключ: ssh-keygen -t rsa
    Открытый и закрытый ключ (id_rsa.pub и id_rsa) будет автоматически сохранен в каталоге ~/.ssh/.
    Настройка будет проще, если вы используете пустую кодовую фразу. Если вы не хотите этого делать, продолжайте следовать этому руководству, но также проверьте, пожалуйста, маркер.
  2. ОТ КЛИЕНТА . Скопируйте открытый ключ в сервер : ssh-copy-id [email protected]
    Открытый ключ клиента будет скопирован на расположение сервера ~/.ssh/authorized_keys.

  3. ОТ КЛИЕНТА - Подключение к серверу: ssh [email protected]

Теперь, если он не работает после описанных 3 шагов, попробуйте следующее:

  • Проверьте права на папку ~/ssh на машине клиент и сервер .
  • Проверьте /etc/ssh/sshd_config на сервере , чтобы убедиться, что RSAAuthentication, PubkeyAuthentication и UsePAM не отключены, их можно включить по умолчанию с помощью yes.
  • Если вы ввели кодовую фразу при создании своего клиентского ключа, вы можете попробовать ssh-agent & ssh-add для доступа к сеансам без пароля.
  • Проверьте содержимое /var/log/auth.log на сервере , чтобы найти проблему, по которой пропущена аутентификация ключа.
ответил marc 19 MarpmSat, 19 Mar 2016 22:56:23 +03002016-03-19T22:56:23+03:0010 2016, 22:56:23
0

Мой сценарий состоял в том, что у меня есть NAS-сервер, на котором я создал пользователь backupbot после создания моей основной учетной записи, который смог войти в систему, чтобы изначально создать backupbot пользователя. После запуска sudo vim /etc/ssh/sshd_config и создания пользователя backupbot, vim может создать, по крайней мере, Ubuntu 16.04 и на основе вашего кода ~/.vimrc, файла подкачки слева от редактирования сеанса vim для /etc/ssh/sshd_config

Проверьте, существует ли: /etc/ssh/.sshd_config.swp, и если он удаляет его и перезапускает демон sshd:

sudo rm /etc/ssh/.sshd_config.swp sudo service sshd restart

Это волшебное решение моей проблемы. Я ранее проверял все мои права и даже отпечатки пальцев RSA открытых и закрытых ключей. Это странно и, вероятно, ошибка с sshd OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016

ответил rivanov 26 72017vEurope/Moscow11bEurope/MoscowSun, 26 Nov 2017 06:37:30 +0300 2017, 06:37:30
0

У меня была такая же проблема с подключением PuTTY к машине Ubuntu 16.04. Это вызывало недоумение, потому что программа pscp от PuTTY работала нормально с одним и тем же ключом (и тот же ключ работал в PuTTY для подключения к другому хосту).

Благодаря ценному комментарию от @UtahJarhead, я проверил файл /var/log/auth.log и нашел следующее:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Оказывается, что новые версии OpenSSH по умолчанию не принимают ключи DSA. Как только я переключился с DSA на RSA-ключ, он работал нормально.

Другой подход: в этом вопросе обсуждается, как настроить SSH-сервер для приема ключей DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq=1 а >

ответил Chad 19 PMpThu, 19 Apr 2018 17:44:28 +030044Thursday 2018, 17:44:28

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132