Чому я все-таки отримую запит на введення пароля з ssh з аутентифікацією відкритого ключа?

Я працюю над URL-адресою, яку я знайшов тут:

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

Мій ssh-клієнт - це настільний комп'ютер Ubuntu 64-bit 11.10, а мій сервер - Centos 6.2 64-бітний. Я дотримувався вказівок. Я все одно отримую підказку про пароль на ssh.

Я не впевнений, що робити далі.

Переконайтесь, що дозволи на ~/.sshкаталог та його вміст є правильними. Коли я вперше налаштував свій ключ ssh 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 і похідних) , які виправлені коди , щоб дозволити групі writability , якщо ви є єдиним користувачем в групі.}

Якщо у вас є кореневий доступ до сервера, найпростіший спосіб вирішити подібні проблеми - це запустити sshd в режимі налагодження, видавши щось на кшталт /usr/sbin/sshd -d -p 2222сервера ( which sshdможе допомогти повний шлях до виконуваного файлу 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 на тому ж сервері працює з ключем auth. Якщо це так, ви можете перемістити свій файл 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

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

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

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

Щоб вручну виправити ACL-адреси SElinux для кореневого користувача:

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 за замовчуванням на той, який містив користувач @ 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 / Author_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'oh!

Раніше я стикався з деякими навчальними посібниками, які описують, як домогтися налаштування 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. Це було дивовижно, тому що програма PSTP 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

Ці кроки повинні допомогти вам вийти. Я використовую це регулярно серед багатьох 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. Тут ми можемо побачити це, виконавши a pstree -pa|less.

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

Дізнавшись, що під 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 не дозволений, оскільки обліковий запис заблоковано - він лише не зміг, оскільки для цього журнал недостатньо багатослівний. Але ми вже знаємо, що в пабкі відхилено, оскільки обліковий запис був заблокований.

Це ще не рішення - тепер нам потрібно google, що означає "заблокований обліковий запис" у випадку sshd. Це буде, швидше за все, якась тривіальна /etc/passwd, /etc/shadowмайстерність, але важливо зробити - проблема не таємнича, а легко відладжувальна / googlable.

У моєму випадку я мав усі права, і навіть під час запуску ssh із прапорцем -vvv я не міг зрозуміти, у чому проблема.

Тому я створив новий сертифікат на віддаленому хості

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

і скопіював згенеровані ключі на локальну машину та додав новий відкритий ключ до ~ / .ssh / санкціонованих_ ключів на віддаленому хості

cat id_rsa.pub >> authorized_keys

Використання згенерованих ключів від підключення віддаленого хост-машини зараз працює. Тож якщо інші рішення не вдається, це спробувати ще одну річ.

Мій сценарій полягав у тому backupbot, що після створення мого основного облікового запису у мене був сервер NAS, на якому я створив користувача, який міг увійти, щоб спочатку створити backupbotкористувача. Після зібрання sudo vim /etc/ssh/sshd_configта створення backupbotкористувача, ви vimможете створити принаймні на Ubuntu 16.04 і, виходячи з вашого ~/.vimrcконфігурації, файл swap, що залишився від редагування вашого сеансу 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 року