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

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

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Мой ssh-клиент - Ubuntu 64 bit 11.10 desktop, а мой сервер - Centos 6.2 64 bit. Я следовал инструкциям. Я все еще получаю запрос пароля на SSH.

Я не уверен, что делать дальше.

Убедитесь, что разрешения для ~/.sshкаталога и его содержимого являются правильными. Когда я впервые настроил свою аутентификацию по ssh-ключу, у меня не было ~/.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 ).

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

Если у вас есть root-доступ к серверу, простой способ решить такие проблемы - запустить sshd в режиме отладки, выполнив что-то вроде /usr/sbin/sshd -d -p 2222на сервере (требуется полный путь к исполняемому файлу sshd, which sshdможет помочь), а затем подключиться с клиента ssh -p 2222 user@host. Это заставит демон 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

(В зависимости от вашего дистрибутива Linux первая / последняя строка может быть systemctl stop sshd.service/ systemctl start sshd.serviceвместо.)

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

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

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Это позволяет нескольким пользователям иметь доступ по SSH без ущерба для прав доступа.

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

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

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

1. ssh-keygen

   Нажмите клавишу Enter, пока не получите приглашение

2. ssh-copy-id -i root@ip_address

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

3. ssh root@ip_address

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

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

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

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

restorecon -R -v /root/.ssh

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

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

ssh -vv user@host

Мы обнаружили, что ключ по умолчанию (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: user@myclient                                          
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

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

• «да» - «нет» для ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• от «нет» до «да» для PubkeyAuthentication

Основано на http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

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

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

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

AuthorizedKeysFile .ssh / authorized_keys

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

service sshd reload

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

cat your_public_key.pub >> .ssh/authorized_keys

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

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

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

/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

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

[root@sys-135 ~]# 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

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

[root@sys-135 ~]# chmod 750 /root

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

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

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

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

chown -R root:root /root

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

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

D'о!

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

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

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

• Проверьте ~/sshправа доступа к папке на компьютере клиента и сервера .
• Проверьте /etc/ssh/sshd_configв сервере , чтобы обеспечить RSAAuthentication, PubkeyAuthenticationи UsePAMварианты не отключены, они могут быть включены по умолчанию с yes.
• Если вы ввели ключевую фразу при генерации ключа клиента, то вы можете попробовать ssh-agentи ssh-addдобиться беспарольной связи в сеансе.
• Проверьте содержимое /var/log/auth.logна сервере, чтобы выяснить, почему проверка подлинности ключа вообще пропускается.

У меня была точно такая же проблема с подключением PuTTY к машине с Ubuntu 16.04. Это было загадочно, потому что программа PuTTY pscp работала нормально с тем же ключом (и тот же ключ работал в 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

Эти шаги должны помочь вам. Я использую это регулярно среди многих 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

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

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

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

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

Дополнительный фон, чтобы помочь любому в той же ситуации: я подключаюсь с хоста, на котором работает Dropbear, к хосту, на котором работает OpenSSH. С PasswordAuthenticationи UsePAMкак установить noна удаленной машине, я получаю следующее сообщение , если я ввожу ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

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

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

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

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

# rm -rf ~/.ssh

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

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

На сервере:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

Это было directory permission issue. Это было 777 на сервере, так I changed it back to 700. Это fixedмоя проблема ssh password less login failureдаже после копирования $USER/.ssh/id_rsa.pubна сервер $USER/.ssh/authorized_keys.

Еще одним вариантом является вариант @Jagadish «s ответ : к straceSSH - демон.

Это имеет существенное преимущество: нам не нужно останавливать sshd, что может привести к полной блокировке, если что-то пойдет не так.

Сначала мы находим pid основного процесса sshd. Здесь мы можем увидеть его выполнение pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Узнав, что pid - 633, мы можем strace, следуя его детям:

strace -p 633 -s 4096 -f -o sux

В результате все, что сделал этот sshd и его дочерние процессы, будет помещено в файл с именем suxв локальном каталоге.

Тогда воспроизведите проблему.

У него будет огромный список журнала вызовов ядра, который в основном непонятен / не важен для нас, но не везде. В моем случае, важно было следующее:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

Это означало, что sshd попытался записать в журнал сообщение User cica, не разрешенное, потому что учетная запись заблокирована - он только не смог, потому что для этого недостаточно подробного ведения журнала. Но мы уже знаем, что pubkey был отклонен, потому что аккаунт был заблокирован.

Это еще не решение - теперь нам нужно гуглить, что означает «заблокированный аккаунт» в случае с sshd. Это будет , скорее всего , некоторое тривиальное /etc/passwd, /etc/shadowколдовство, но главное сделано - проблема не загадочная, но легко отладка / googlable один.

В моем случае у меня были все права, и даже при запуске ssh с флагом -vvv я не мог понять, в чем проблема.

Поэтому я сгенерировал новый сертификат на удаленном хосте

ssh-keygen -t rsa -C "your_email@example.com"

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

cat id_rsa.pub >> authorized_keys

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

Мой сценарий состоял в том, что у меня есть сервер 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 марта 2016 г.