Аутентификация по SSH-ключу не удалась

Question 1

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

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

(Это то, чтоПользовательскийавтоматически в своем скрипте «shim» обновляет и исправляет любые проблемы с разрешениями на основе изменений в веб-панели управления команды.)

Если ваш администратор создал каталог .ssh/ или файл .ssh/authorized_keys как пользователь root (что чаще всего и приводит к сбоям), то иметь файл в собственности другого пользователя не допускается, ДАЖЕ если этот пользователькорень.

Answer

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

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

(Это то, чтоПользовательскийавтоматически в своем скрипте «shim» обновляет и исправляет любые проблемы с разрешениями на основе изменений в веб-панели управления команды.)

Если ваш администратор создал каталог .ssh/ или файл .ssh/authorized_keys как пользователь root (что чаще всего и приводит к сбоям), то иметь файл в собственности другого пользователя не допускается, ДАЖЕ если этот пользователькорень.

Question 2

У меня была точно такая же проблема на двух серверах: Linux под управлением Debian Stretch и NAS (Synology DS715)

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

auth.log на сервере был очень полезен

Authentication refused: bad ownership or modes for directory /home/cyril

в Linux был включен бит записи/группы (drwxrwxr--x), поэтому мне пришлось удалить как минимум группу записи (chmod gw ~/), и тогда это сработало

на Synology, по какой-то причине, был липкий кусочек

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Мне пришлось его поменять

chmod -t ~/

и я мог бы тогда подключиться без пароля

Answer

У меня была точно такая же проблема на двух серверах: Linux под управлением Debian Stretch и NAS (Synology DS715)

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

auth.log на сервере был очень полезен

Authentication refused: bad ownership or modes for directory /home/cyril

в Linux был включен бит записи/группы (drwxrwxr--x), поэтому мне пришлось удалить как минимум группу записи (chmod gw ~/), и тогда это сработало

на Synology, по какой-то причине, был липкий кусочек

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Мне пришлось его поменять

chmod -t ~/

и я мог бы тогда подключиться без пароля

Question 3

При использовании CentOS 7, и я уверен, что это применимо и к другим ОС Linux, использующим sshd. С правами root вы можете определить больше о том, почему может не проходить аутентификация. Для этого:

Включите ведение журнала для sshdдемона:sudo vi /etc/ssh/sshd_config
В разделе «Логирование» раскомментируйте:

SyslogFacility AUTH
LogLevel INFO

Изменить LogLevelс INFOнаDEBUG
Сохранить и выйти
Перезапустите демон SSH с помощьюsudo systemctl restart sshd
Смотреть файл сообщенийtail -l /var/log/messages
Используя другой терминал, попробуйте подключиться по ssh
Попытайтесь связаться сssh
Проверьте журнал аутентификации, чтобы узнать точную причину.

Например, я столкнулся с некоторыми из тех же проблем, что упомянуты выше.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Используя эти шаги, я смог подтвердить, что проблема была в разрешениях на authorized_keysфайл. Установив chmod 644на authorized_keysфайл моего пользователя, проблема была устранена.

Answer

При использовании CentOS 7, и я уверен, что это применимо и к другим ОС Linux, использующим sshd. С правами root вы можете определить больше о том, почему может не проходить аутентификация. Для этого:

Включите ведение журнала для sshdдемона:sudo vi /etc/ssh/sshd_config
В разделе «Логирование» раскомментируйте:

SyslogFacility AUTH
LogLevel INFO

Изменить LogLevelс INFOнаDEBUG
Сохранить и выйти
Перезапустите демон SSH с помощьюsudo systemctl restart sshd
Смотреть файл сообщенийtail -l /var/log/messages
Используя другой терминал, попробуйте подключиться по ssh
Попытайтесь связаться сssh
Проверьте журнал аутентификации, чтобы узнать точную причину.

Например, я столкнулся с некоторыми из тех же проблем, что упомянуты выше.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Используя эти шаги, я смог подтвердить, что проблема была в разрешениях на authorized_keysфайл. Установив chmod 644на authorized_keysфайл моего пользователя, проблема была устранена.

Question 4

у меня былопохожая проблема, где соединение ssh пытается ввести ключ, ~/.ssh/id_rsaпрежде чем неожиданно остановиться на:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

В моем случае это произошло из-за старого файла открытого ключа, который лежал в .sshкаталоге:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Перемещение/удаление id_rsa.pubиз .sshкаталога решило проблему.

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

Я отправил электронное письмо в список рассылки openssh:https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html.

Answer

у меня былопохожая проблема, где соединение ssh пытается ввести ключ, ~/.ssh/id_rsaпрежде чем неожиданно остановиться на:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

В моем случае это произошло из-за старого файла открытого ключа, который лежал в .sshкаталоге:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Перемещение/удаление id_rsa.pubиз .sshкаталога решило проблему.

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

Я отправил электронное письмо в список рассылки openssh:https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html.

Аутентификация по SSH-ключу не удалась

решение1

решение2

решение3

решение4

Связанный контент