Вы еще не авторизуетесь по ключам? Тогда мы идем к вам / Хабр

Почему не работает авторизация по ключу ssh?

Проблема встречается часто, но я пока не нашел решения, которое мне поможет.

Я пытаюсь подключиться из Win10 к Oracle Linux 8.3, поднятой локально на виртуальной машине.

Версия OpenSSH на клиенте: OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
На сервере: OpenSSH_8.0p1, OpenSSL 1.1.1g FIPS

Алгоритм:
1) Утилитой ssh-keygen сгенерировал пару ключей, они появились в папке моего профиля C:UsersRoma.ssh
2) На сервере создал директорию для пользователя nodejs /home/nodejs/.ssh/authorized_keys и положил в нее is_rsa.pub
3) Сделал вдалельцем .ssh и файла пользователя nodejs:users и дал права 700
4) Проверил, что в /etc/ssh/sshd_config строка “PubkeyAuthentication yes” не закомментирована
5) Настроил проброс 22-го порта на виртуальную машину, проверил, что могу зайти через WinSCP (по паролю).

При попытке подключиться командой:
ssh -v localhost

Получаю лог:

debug1: Reading configuration data C:\Users\Roma/.ssh/config
debug1: C:\Users\Roma/.ssh/config line 1: Applying options for localhost
debug1: Connecting to localhost [::1] port 22.
debug1: connect to address ::1 port 22: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file C:\Users\Roma/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_ed25519-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_xmss type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\Users\Roma/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:22 as 'nodejs'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:lIEJUSqFGQ90czXuJzvda7VNciQOxHVm2XL4bEE5Z/I
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in C:\Users\Roma/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:wobbldI9m9m9rs KGa 7jyVTnYu2nSEkp4qwHIoS3zI C:\Users\Roma/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: C:\Users\Roma/.ssh/id_dsa
debug1: Trying private key: C:\Users\Roma/.ssh/id_ecdsa
debug1: Trying private key: C:\Users\Roma/.ssh/id_ed25519
debug1: Trying private key: C:\Users\Roma/.ssh/id_xmss
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
nodejs@localhost's password:

То есть ключ, как я понимаю, отправляется?

Похожее:  OpenSSH авторизация по RSA ключам

Логов авторизации не сервере так и не нашел:

[root@ora19c ~]# find /var -name *auth*
/var/lib/selinux/targeted/active/modules/100/authconfig
/var/lib/selinux/targeted/active/modules/100/authlogin
/var/lib/selinux/targeted/active/modules/100/pwauth
/var/lib/polkit-1/localauthority
/var/lib/authselect
[root@ora19c ~]#

В чем может быть проблема?

Вход по ssh ключу для локальных администраторов windows

В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.

Вы еще не авторизуетесь по ключам? тогда мы идем к вам

Этой заметкой я хочу показать, что использовать ключи для авторизации это просто.

Начнем с того, что нам понадобится PuTTY.
Идем на http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html и качаем следующее:
PuTTY — ssh-клиент
Pageant — агент для хранения ключей (зачем объясню позже)
PuTTYgen — генератор ключей

Сначала сгенерируем ключи, потом настроим PuTTY, и в конце покажу как всем этим пользоваться.

Создадим папочку для PuTTY и все скинем туда.
Содержимое папки

Запускаем PuTTYgen выбираем “Type of key to generateSSH-2 RSA и 2048-битный ключ.
Основное окно PuTTYgen

Жмем Generate. Следуя указациям, хаотично перемещаем мышку.
Генерация ключей

После генерации нам предстанет следующее.
Вид после генерации

В верхнем поле публичный ключ, который будет храниться у принимающей стороны.
Ах да, я забыл рассказать как происходит непосредственная авторизация с помощью ключей.

Для наглядности возьмем server и client.
client сообщает server’у свой публичный ключ любым доступным способом. Беспокоиться, что кто-то узнает этот ключ не стоит.
Авторизация происходит следующем образом:
дальше следует объяснение человека, который не читал соответствующей литературы, поэтому описывает так, как он себе это представляет
client обращается к server’у и они обмениваются публичными ключами.
на основании этого server авторизует client’а, дает соответствующие права.

Это было небольшое отступление, вернемся к PuTTYgen.

В верхнем поле публичный ключ, который будет храниться у принимающей стороны.
Key fingerprint — отпечаток ключа.
Key comment — комментарий к ключу, я обычно указываю машину, на которой это ключ используется.
Key passphrase — парольная фраза к приватному ключу. Ее следует сделать сложной. Конечно можно оставить пустой, и тогда при авторизации не будет требоваться пароль, но дальше я покажу, что даже с сложным паролем к ключу можно авторизовываться без повторного ввода пароля, будто пароля и нет.
Confirm passphrase — подтверждение парольной фразы.

Дальше нужно сохранить сгенерированные ключи. Остановлюсь только на приватном ключе. При сохранении (Save private key) предложится сохранить ключ с расширением .ppk. Он будет использоваться Pageant в дальнейшем.

Перед тем, как мы перейдем к настройке PuTTY, расскажу о возможности восстановить публичный ключ из приватного с помощью PuTTYgen.
Для этого нужно нажать кнопку Load. Указать приватный ключ. Ввести парольную фразу (если имеется) и отобразится точно такое же окно, как на предыдущем скриншоте.

Теперь запустим PuTTY и сделаем предварительные настройки.
Выберем Default Settings и нажмем Load.
Перейдем слева на Session->Logging, отметим галочкой Printable output. В поле Log file name впишем logs&H_&Y-&M-&D-&T.log, уберем галочку Flush log file frequently.
Таким образом, мы указали, что хранить логи будем в папочке logs, рядом с PuTTY.exe с именами на подобии 192.168.1.6_2022-08-29-101304.log
Перейдем на вкладку Window->Translation. И выберим в списке Remote character setUTF-8, чтобы не было проблем с кодировкой.
В Connection->SSH->Auth проверим, что стоит галочка напротив Attempt authentication using Pageant и укажем путь к приватному ключу в графе Private key file for authentication.
После этого вернемся на вкладку Session нажмем сохранить, чтобы указанные настройки были по-умолчанию.

Пришло время показать работу авторизации, используя ключи, на практике.
Воспользуемся агентом для хранения ключей Pageant.

После запуска, появится иконка в области уведомлений. Жмем правой кнопкой, Add key.
Добавить ключ

Выбираем ключ, указываем парольную фразу. Теперь ключ хранится в памяти.
Чтобы посмотреть ключи, можно выбрать пункт View keys.
Просмотреть ключи

Попробуем авторизоваться.
Открываем PuTTY. Указываем IP. Жмем Open.
В первый раз выскочит предупреждение, что раньше мы не использовали ключ для авторизации на этом сервере. Когда такое возникает впервый раз, это нормально, но если такое возникает на сервере, на котором мы уже авторизовывались, то либо сервер сменил свои ключи, либо это фейковый сервер.
Предупреждение, о отсутствии в кеше слепка ключа сервера

Вводим логин. Жмем Enter. И мы автоматически авторизовались.
Успешное подключение по ssh

Покажу еще, на примере Komodo Edit.
Выбираем File->Open->Remote open
Пункт в меню

Выбираем Accounts. Потом New Server.
В Server Type указываем SCP. В Name произвольное название для сервера. В Hostname ip сервера (или доменное имя). В User Name логин пользователя.
Жмем Add, затем OK.
В верхнем выпадающем меню выбираем наш сервер. Если сервер разрешает авторизацию по ключам, то мы увидим список директорий на сервере, выбираем нужный файл и редактируем (при наличии прав на запись у пользователя).
image

PS: Следующая ошибка появляется в том случае, если сервер поддерживает только авторизацию по ключам, а у вас не включен Pageant.
Error: Remote SSH server does not allow password authentication. Allowed types are: publickey

PS2:
Не пропустите полезную статью Памятка пользователям ssh

Генерация ssh ключей на клиенте windows

На клиентском, компьютере, с которого вы будет подключаетесь к удалённому серверу Windows с OpenSSH, вам нужно сгенерировать пару ключей (открытый и закрытый). Закрытый ключ хранится на клиенте (не отдавайте его никому!), а открытый ключ нужно скопировать в файл authorized_keys на SSH сервере. Чтобы сгенерировать SSH ключи на клиенте Windows, вы должны установить клиент OpenSSH.

В Windows 10/11 и Windows Server 2022/2022 клиент OpenSSH устанавливается как отдельный встроенный компонент с помощью PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару ED25519 ключей:

ssh-keygen -t ed25519

По умолчанию утилита ssh-keygen генерирует ключи RSA 2048. В настоящий момент вместо RSA ключей рекомендуется использовать именно ED25519.

Утилита попросит вас указать пароль для защиты закрытого ключа. Если вы укажете пароль, то каждый раз при использовании этого ключа для SSH авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).

Логирование ssh подключений по сертификату

Мне необходимо знать, когда и какой сертификат подключался к серверу. По-умолчанию такой информации чаще всего в логах не остается. Исключение я заметил только в CentOS 7. Там с дефолтными настройками ssh и уровнем логирования INFO отображается отпечаток ключа в логе:

# cat /var/log/secure

Настройка openssh в windows для авторизации по ключам

SSH сервер (в этом примере это удаленный компьютер с Windows 11 и настроенной службой OpenSSH).

Не работает вход по ключу для нового пользователя centos

довольно часто это связано с неправильной принадлежностьи и/или правами каталога .ssh и/или его содержимого.

  1. исправить принадленость:

    $ sudo chown -R пользователь:группа /путь/к/каталогу/.ssh
    

    где группа — это основная группа пользователя. уточнить её можно с помощью:

    $ id пользователь
    uid=номер(пользователь) gid=номер(группа) …
    
  2. исправить права:

    $ sudo chmod -R go= /путь/к/каталогу/.ssh
    

также стоит убедиться, что вы поместили именно публичную часть ключа (id_rsa.pub или id_dsa.pub) в файл authorized_keys, и что этот файл располагается именно в каталоге .ssh в домашнем каталоге созданного пользователя.


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

$ ssh-copy-id пользователь@сервер

Помогла статья? подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *