Вход в личный кабинет Почему не работает авторизация по ключу 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:То есть ключ, как я понимаю, отправляется?
Логов авторизации не сервере так и не нашел:
[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 generate” SSH-2 RSA и 2048-битный ключ.
Жмем 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. И мы автоматически авторизовались.
Покажу еще, на примере Komodo Edit.
Выбираем File->Open->Remote open
Выбираем Accounts. Потом New Server.
В Server Type указываем SCP. В Name произвольное название для сервера. В Hostname ip сервера (или доменное имя). В User Name логин пользователя.
Жмем Add, затем OK.
В верхнем выпадающем меню выбираем наш сервер. Если сервер разрешает авторизацию по ключам, то мы увидим список директорий на сервере, выбираем нужный файл и редактируем (при наличии прав на запись у пользователя).
PS: Следующая ошибка появляется в том случае, если сервер поддерживает только авторизацию по ключам, а у вас не включен Pageant.
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 и/или его содержимого.
исправить принадленость:
$ sudo chown -R пользователь:группа /путь/к/каталогу/.sshгде
группа— это основная группа пользователя. уточнить её можно с помощью:$ id пользователь uid=номер(пользователь) gid=номер(группа) …исправить права:
$ sudo chmod -R go= /путь/к/каталогу/.ssh
также стоит убедиться, что вы поместили именно публичную часть ключа (id_rsa.pub или id_dsa.pub) в файл authorized_keys, и что этот файл располагается именно в каталоге .ssh в домашнем каталоге созданного пользователя.
вообще, чтобы избежать подобных вышеописанным проблем, удобнее копировать публичный ключ с помощью программы ssh-copy-id:
$ ssh-copy-id пользователь@сервер
Помогла статья? подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.