LINUX.ORG.RU

SSH не заходит по файлу с ключом

 , ,


0

1

Есть плеяда серверов. Настройкой и поддержкой занимаюсь не я. Мне нужно лишь на них заходить по SSH

Под виндой (да-да, основная рабочая ОС у нас винда) сгенерил ssh-keygen'ом RSA ключ со всеми настройками по умолчанию, вот просто запустил ssh-keygen, ENTER, ENTER, ENTER.

Раскидал содержимое .pub на все сервера в ~/.ssh/authorized_hosts

На все сервера успешно заходит. Кроме одного. Этот проблемный имеет отличный от других IP и может на нём другие настройки

Вот что пишет ssh на стороне клиента https://pastebin.com/qpegfuhN

Кому лень кликать, последние строчки:

debug1: Offering public key: RSA SHA256:QosAzEmjK2Iv8v2bREsKSfQzxJT/1BjR0LZ7q12EHnk C:\\Users\\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
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
user@srv-test's password:

Что пробовал:

1. Проверил что захожу под тем же юзером, для которого в ~/.ssh/authorized_keys прописал ключ

2. Проверил что пишу именно в тот ~/.ssh/authorized_keys на сервере. Там кроме моего ключа есть и другие, после праздников узнаю у них, заходит ли

3. Поигрался с правами на ~/.ssh и файлы в ней, пробовал и 700 и 600 как рекомендуют, ничего не помогло, вернул обратно.

4. Проверил формат файла authorized_keys, каждая строчка начинается с ssh-rsa и оканчивается USER@COMP

5. Убедился что мой ключ точно такой же длины и формата, как и другие ключи в authorized_keys, все начинаются с AAAAB

6. Исключил несовместимость версий (может ключ слишком новой версии и сервер его не понимает) - сгенерил ключ на самом сервере, перенёс себе приватный - не заходит

7. Пробовал генерить разные форматы ключей, rsa, dsa - не помогло

8. Проверил что в конфиге демона SSHD файл с ключами смотрит именно в домашней директории

9. Стопать демона SSHD чтобы запустить с отладочным выводом - нельзя, локального доступа к серверу нет, можно лишь смотреть логи клиента

Клиент

ssh -V
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

Проблемный сервер (кажется centos)

$ ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017

$ uname -a
Linux testfood-app 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Нормальный сервер (кажется тоже centos)

$ ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017

uname -a
Linux food-webapi-1 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Что ещё попробовать?



Последнее исправление: D_Lans (всего исправлений: 1)

9. Стопать демона SSHD чтобы запустить с отладочным выводом - нельзя, локального доступа к серверу нет, можно лишь смотреть логи клиента

Проблему искать с этого места для начала.

Конфиги сервера доступны для чтения?

kardapoltsev ★★★★★
()
Ответ на: комментарий от deadNightTiger

Проблемный сервер:

$ ls -laZ ~/.ssh
drwxrwxr-x. user user unconfined_u:object_r:ssh_home_t:s0 .
drwxrwxrwx. user user unconfined_u:object_r:user_home_dir_t:s0 ..
-rw-rw-r--  user user ?                                authorized_keys
-rw-r--r--  user user ?                                known_hosts

Нормальный:

$ ls -laZ ~/.ssh
drwxr-xr-x. user user unconfined_u:object_r:ssh_home_t:s0 .
drwx------. user user unconfined_u:object_r:user_home_dir_t:s0 ..
-rw-------. user user unconfined_u:object_r:ssh_home_t:s0 authorized_keys
-rw-r--r--. user user unconfined_u:object_r:ssh_home_t:s0 known_hosts

Проблемный:

$ getenforce
Disabled

Нормальный:

$ getenforce
Enforcing

D_Lans
() автор топика
Ответ на: комментарий от D_Lans

man sshd:

 ~/.ssh/authorized_keys
         Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used
         for logging in as this user.  The format of this file is
         described above.  The content of the file is not highly sensi‐
         tive, but the recommended permissions are read/write for the
         user, and not accessible by others.

         If this file, the ~/.ssh directory, or the user's home directory
         are writable by other users, then the file could be modified or
         replaced by unauthorized users.  In this case, sshd will not
         allow it to be used unless the StrictModes option has been set to
         “no”.
deadNightTiger ★★★★★
()
Последнее исправление: deadNightTiger (всего исправлений: 1)
Ответ на: комментарий от deadNightTiger

Установил

chmod 700 ~
chmod 700 ~/.ssh
chmod 700 ~/.ssh/authorized_keys

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

Всем спасибо.

D_Lans
() автор топика
23 августа 2020 г.
Ответ на: комментарий от D_Lans

А можно с вами как-то пообщаться? Про вот этот пост: Базовый вопрос по хранению информации на ПК

Написать мне можно по моему нику в телеге или на хабре.

embden
()
Последнее исправление: embden (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.