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

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

[ ! -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

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

cat your_public_key.pub >> .ssh/authorized_keys

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

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

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

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

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Это позволяет многочисленным пользователям иметь этот ssh доступ, не ставя под угрозу полномочия.

Если у Вас есть корневой доступ к серверу, простой способ решить такие проблемы состоит в том, чтобы выполнить 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 вместо этого.)

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

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

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

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

Может случиться так, что просто необходимо не прокомментировать строку:

AuthorizedKeysFile .ssh/authorized_keys

Следите за этим, необходимо перезагрузить ssh сервис для изменений для происхождения:

service sshd reload

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

1. ssh-keygen

   Нажмите клавишу Enter, пока Вы не получите подсказку

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

   (Это однажды попросит пароль хост-системы),

3. ssh root@ip_address

   Теперь необходимо смочь войти в систему без любого пароля

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

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

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

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

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

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

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

chown -R root:root /root

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

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

D'oh!

SELinux на Redhat / Centos 6 имеет проблему с аутентификацией PUBKey , вероятно, когда некоторые файлы созданы SELinux, не устанавливает его правильно.

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

restorecon -R -v /root/.ssh

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

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

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 по умолчанию на тот, который содержал пользователь @ MyClient. Когда ключ по умолчанию, нет проверки на имя клиента.

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

'Agent admitted failure to sign using the key'

Это было решено путем перезарядки ключей в SSH-агент:

ssh-add

У меня только что имела эту же проблему, и для меня решение было установлено USEPAM на № . Видите, даже с PasswordAuthenticatication установлено на NO , вы все равно получите клавиатуру-интерактивное , и в моем случае моя локальная программа SSH сохранила по умолчанию для этого некоторая причина.

Дополнительный фон для того, чтобы помочь кому-либо с той же ситуацией: я подключаюсь от хоста, бегающего Dropbear к одному запуску OpenSSH. С PasswordAuthicentication и USEPAM Оба набора NO на удаленном компьютере, я получу следующее сообщение, если я введем SSH User @ Server :

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

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

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

Чтобы воспользоваться преимуществами безопасности -execdir (который на самом деле заключается в том, чтобы убедиться, что команда не получает путь с несколькими компонентами) и получить подсказку, можно использовать:

find . -name hello.c -okdir rm -f {} \;

(обратите внимание, что по крайней мере реализация GNU find не избегает имен файлов способом, подходящим для терминалов, как это делает GNU rm (wr

эхо - настройка терминального устройства (дисциплина в драйвере tty kernel), termcap - это управление терминалом (реальным или эмулятором) через побег последовательностей, это две отдельные вещи.

Здесь необходимо запретить приложению выполнять определенный ioctl . Одним из способов может быть отсоединение его от терминала.

socat - exec:okular,pty,raw

Запускает okular , подключенный к другому псевдотерминалу, и socat передает данные с терминала на этот.

Чтобы передать произвольные аргументы, с zsh , bash или ksh93 :

okular() {
  CODE=$(printf '%q ' exec okular "$@"
        ) socat - 'system:"eval \"$CODE\"",pty,raw'
}

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

/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

Проверка подлинности ключа запущена.

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

• 'yes' на 'no' для ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• 'no' на 'yes' для PubkeyAuthentication

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

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

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

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

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

Проверив разрешения и попробовав несколько других решений, перечисленных здесь, я наконец удалил каталог 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

У меня была точно такая же проблема с подключением 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

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

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

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

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

cat id_rsa.pub >> authorized_keys

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

Еще один вариант — это вариант ответа @Jagadish:наstraceдемона ssh.

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

Это еще не решение -теперь надо гуглить, что означает "заблокированный аккаунт" в случае с sshd. Скорее всего, это будет какое-то тривиальное /etc/passwd, /etc/shadowволшебство,но главное сделано -проблема не таинственная, а легко поддающаяся отладке/поиск в Google.

На сервере:

$ 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.

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

Вы можете использовать флаг -vvv, чтобы определить, была ли попытка получить закрытый ключ, (и какие именно ключи )и почему ключи (с )не работают. Пример:ssh -T -vvv myHost.com. В качестве альтернативы вы можете использовать LogLevel DEBUG3в ~/.ssh/config.

Распространенный сбой заключается в том, что сервер отклоняет ключ. В этом случае вы увидите что-то вроде этого:

debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/myUsername/.ssh/id_rsa
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
myUsername@myServer.com's password:

Согласно официальной спецификации протокола SSH (RFC 4252 ), пакеты аутентификации имеют следующие значения:

SSH_MSG_USERAUTH_REQUEST    50
SSH_MSG_USERAUTH_FAILURE    51
SSH_MSG_USERAUTH_SUCCESS    52

Это означает, что debug3: receive packet: type 51указывает, что сервер отклонил ключ.

У меня была такая же проблема при подключении с Raspbian8 на Fedora34.

Ошибка отладки, которую я получил::

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

Решение состояло в том, чтобы добавитьssh -rsaк значению PubkeyAcceptedAlgorithms в

/etc/crypto-policies/back-ends/opensshserver.config

и перезапустите службу

thanks to Dave @ https://wiki.xdroop.com/space/Fedora/34/SSH+Pubkey+doesn%27t+work for this solution

Я попытался войти в аккаунт коллеги без пароля, вставив id _rsa.pub в ее авторизованный файл _ключей. Я получил права доступа ко всем соответствующим файлам, но все равно не смог добиться успеха с паролем -без входа в систему.

Оказывается, так как я создал авторизованный файл ключей _с правами root, мне пришлось chown и chgrp на те, которые соответствуют ее профилю.

sudo chown ${username} -R /home/${username}/.ssh
sudo chgrp ${groupname} -R /home/${groupname}/.ssh

Эту ошибку было легко обнаружить при использовании режима тройного подробного вывода ssh -vvv.