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

470

Я работаю с 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.

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

Thom
источник
5
вывод команды ssh с флагом -v? должно быть похоже на этот pastebin.com/xxe57kxg
Роб
14
также убедитесь, что ваша папка .sshchmod 700
Rob
8
Предполагая, что у вас есть root-доступ к серверу, /var/log/auth.logвы узнаете, почему не удается войти в систему.
UtahJarhead
5
@UtahJarhead: На сервере CentOS он, скорее всего, будет /var/log/secure.
Деннис Уильямсон
3
Интересно, что chmod 0700был ответом, но когда я сделал ssh -vна стороне клиента, это не указывало на ошибку, связанную с тем, почему ключ не был принят, он просто сказал, что пытается следующий пароль, хотя мой клиент отправил открытый ключ. Как они ожидают, что мы диагностируем проблемы без информации об ошибках с сервера?
void.pointer

Ответы:

557

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

обкрадывать
источник
29
Большое спасибо за указание restorecon. Я почесал свою голову в этом вопросе уже некоторое время.
Ричард Баррелл
19
Как ни странно, у меня возникли проблемы с учетной записью, которую друг установил на своем VPS, и работающей в режиме аутентификации pubkey. Я думал, что все разрешения были правильными, но важно помнить, что это /home/USERдолжно быть 700или755
Роб
2
Также не забудьте проверить настройки владельца и группы, я использовал RSYNC для копирования файла author_keys и не заметил, что для владельца / группы было установлено значение 1000 вместо root!
нак
11
также добавьте -v к вашей команде ssh, чтобы увидеть, что происходит с этим ключом. ssh -v user@host,
tedder42
14
chmod -R 700 ~/.sshработал для меня, чтобы встретить ограничения этого ответа (RHEL 7)
scottyseus
147

Если у вас есть 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вместо.)

Tgr
источник
5
Я просто попытался это ... и она отлично работает , когда я бегу sshd -d, но терпит неудачу , когда я на самом деле работать service sshd start. Я уверен, что это просто, но я не гуру Linux. есть идеи?
Н Ролер
3
Для справки, этот пост объясняет решение SELinux, которое решило мою проблему.
Н Ролер
2
У меня также были проблемы с установлением подлинности с открытым ключом, и я был почти уверен, что проблема не в разрешениях каталога. После запуска SSH в режиме отладки я быстро обнаружил, что был неправ, и проблемы были с разрешениями.
ub3rst4r
3
Отличный совет, моя папка пользователя была с неправильными разрешениями.
gdfbarbosa
2
Спасибо. Из-за всех причин моему пользователю не разрешили войти в систему, потому что оболочка, указанная ansible (/ bin / zsh) при создании пользователя, не существовала. Я бы никогда не догадался об этом.
Чишаку
53

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

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

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

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

СЕЕ
источник
3
Этот ответ является выдающимся и помог мне - для всех, кто интересуется, в этом ли проблема - вы можете увидеть «pam_ecryptfs: файл парольной фразы упакован» в вашем auth.log; почему-то этого было недостаточно, чтобы заставить меня вспомнить, что homedir был зашифрован. Также вы можете обнаружить, что при первом входе в систему запрашиваются пароли, а в последующих сеансах - нет (поскольку он расшифровывается, когда открываются другие сеансы).
пацифист
Черт возьми, я долго искал wayyyy, чтобы решить эту проблему, заправляй тебя так сильно!
h3.
33

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

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
gusior
источник
1
На самом деле нет, вы не делаете. ssh автоматически использует ~ / .ssh / id_rsa (или id_dsa) без необходимости использования ключевого агента.
Патрик
7
Это может быть полезным советом, если нужно указать ключ с другим именем в ~ / .ssh / config (например, на хосте * .mydomain.org ... IdentityFile ~ / .ssh / some_limited_use.pub - ssh-add ~ / .ssh / some_limited_use.pub).
89c3b1b8-b1ae-11e6-b842-48d705
Это решило мою проблему с получением пароля после добавления ключа. Как указывалось в 89c3b1b8-b1ae-11e6-b842-48d705, причиной запуска этих команд вручную было нестандартное имя файла ключа.
Михаил Лисаков
Как указано выше в комментариях, если вы используете какой-либо ключ, кроме ключа по умолчанию, он не добавляется по умолчанию к агенту ssh. Поэтому убедитесь, что ключ, который вы хотите использовать, находится в цепочке ключей агента:ssh-add -L
Джеймс
30

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

  1. ssh-keygen

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

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

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

  3. ssh root@ip_address

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

Ravindra
источник
1
На каком сервере?
Амальговинус
@Amalgovinus Очевидно, вы запускаете это на клиенте, а не на машине, к которой вы подключаетесь - вам не нужна копия вашего закрытого ключа на сервере! :)
Невелис
4
Обратите внимание, что, как правило, разрешение удаленного входа в систему root не рекомендуется.
Ариэльф
27

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

Сахил
источник
7
У нас тоже была эта проблема - 755 на домашних
режиссерах
У меня были права доступа 777, и это было проигнорировано, спасибо !!!
ka_lin
Тоже самое. Благодарю. Некоторое время чесал мою голову, что-то случилось.
Марчин
Да, см. Ответ здесь для получения более подробной информации. Unix.stackexchange.com/questions/205842/…
Тим
Это может быть ответом для людей, которые правильно выполнили генерацию ключа, но все еще получают запрос на ввод пароля.
Ферги
14

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

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

restorecon -R -v /root/.ssh
Дэвид Макинтош
источник
используя openssh клиент на windows, я смог без проблем ssh root@mymachineвойти в CentOS6 mymachine, но у меня есть пользователь с более низким уровнем привилегий, который я бы предпочел использовать, но ssh regularUser@mymachineвсе равно запрашивает у меня пароль. мысли?
Groostav
13

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

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

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

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

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

Ниша
источник
1
Как в комментариях к вопросу, проверьте / var / log / secure или /var/log/auth.log. В моем случае я вижу "Пользователь xxx из xxx не разрешен, потому что не указан в AllowUsers" "input_userauth_request: недопустимый пользователь xxx [preauth]" (и "rexec line 35: Устаревшая опция ServerKeyBits" в / var / log / messages, хотя я не знаю, что это). Чтобы решить эту проблему vi /etc/ssh/sshd_config, добавьте пользователя xxx в список AllowUsers, service sshd restart*** ОСТОРОЖНО, перезапуск службы sshd с ошибкой sshd_config может заблокировать вас из коробки !? ***. Это сработало.
прогулка
6

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

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

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

AuthorizedKeysFile .ssh / authorized_keys

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

service sshd reload
Dziamid
источник
4

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

cat your_public_key.pub >> .ssh/authorized_keys

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

Войтек Жепала
источник
Да, я тоже это заметил по поводу перезаписи, но у меня их не было, так что это не имело значения. Я создал символическую ссылку на author_keys2, но это не помогло.
Том
Также проверьте права доступа к файлу / каталогу. Они описаны на сайте, который вы предоставили.
Войтек Жепала
3
ваш ~ / .ssh dir должен быть 700, ваш файл личного ключа должен быть 600, ваш файл открытого ключа должен быть 644, ваш файл аутентификации (на удаленном компьютере) должен быть 644
Роб
@ Роб это была проблема. Если бы вы опубликовали это как ответ, я бы принял это.
Том
4

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

user46932
источник
Я исправил это, изменив поле пароля /etc/shadowдля этого пользователя с !на *. После этого аутентификация по паролю все еще невозможна, но пользователь больше не заблокирован.
user3132194
4

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

/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

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

Jagadish
источник
У меня такая же проблема. Вчера я выдал rsync -av ./root/ root@THE_HOST:/rootкоманду на загрузку некоторых файлов из моего локального рабочего каталога, затем эта проблема возникает (на самом деле, сначала я не заметил этого. После того, как задания cron на других хостах перестали работать на следующее утро, я начал копать причину) , Команда rsync -av ./root/ root@THE_HOST:/rootизменила владельца и права доступа к /rootкаталогу удаленного хоста. Исправлено разрешение, проблема решена.
LiuYan 研 研
Failed publickey for root from 135.250.24.32 port 54553 ssh2Я получаю то же сообщение и выдаю сообщение, когда забыл добавить pubkey к хосту authorized_keys. Добавляя этот комментарий, как и в моем случае, я обычно осознаю свою ошибку после того, как проверил отладку и все разрешения, а также файлы конфигурации #: o <
tuk0z
3

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

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

чхинна
источник
3

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

chown -R root:root /root

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

Будет
источник
Я тоже. Посмотрите на сообщения в / var / log / secure. Я увидел сообщение: «Отказ в аутентификации: неправильное владение или режимы для каталога» ($ HOME). Убедитесь, что нет доступа на запись в $ HOME для группы или другого. Я бы никогда не нашел этого, если бы у меня не было несанкционированного корневого доступа к серверу ....
SoloPilot
2

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

D'о!

Майкл Шепер
источник
Это также параметр конфигурации в / etc / ssh / sshd_config, хотя я думаю, что переименовал бы его, как вы.
Рик Смит,
2

В прошлом я сталкивался с некоторыми учебными пособиями, в которых описывается, как выполнить настройку 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на сервере, чтобы выяснить, почему проверка подлинности ключа вообще пропускается.
Марк
источник
Спасибо за перечисление шагов! Я добрался до «ssh-copy-id user @ server» и понял, что изначально скопировал неправильный открытый ключ.
Маттаватар
2

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

Чад
источник
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-copy-idчто делает последние два шага автоматически.
Джофель
2
@jofel помните, что во многих системах ssh-copy-id не существует. @Sriharsha после того, как mkdirвы chmod 700 .sshтоже должны добавить туда, и, кстати, вам не нужно быть настолько многословным ~/.ssh, .sshдостаточно просто , поскольку команды все равно выполняются в домашнем каталоге
janos
1

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

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

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

Анджей Йозвик
источник
1

У меня просто была такая же проблема, и для меня решение было установить 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, все работает, как ожидалось.

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

Marty
источник
1

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

На сервере:

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

fastrizwaan
источник
0

Еще одним вариантом является вариант @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 один.

user259412
источник
0

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

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

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

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

cat id_rsa.pub >> authorized_keys

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

kovinet
источник
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 марта 2016 г.

rivanov
источник