I tried to connect to planetlab node using ssh. It throws me error like Permission denied (publickey,keyboard-interactive). What does this mean?
Here is the verbose of the exception.
> OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL
> 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for * debug2:
> ssh_connect: needpriv 0 debug1:
> Connecting to planetlab1.csee.usf.edu
> [131.247.2.241] port 22. debug1:
> Connection established. debug1:
> permanently_set_uid: 0/0 debug3: Not a
> RSA1 key file /home/keven/.ssh/id_rsa.
> debug2: key_type_from_name: unknown
> key type '-----BEGIN' debug3:
> key_read: missing keytype debug2:
> key_type_from_name: unknown key type
> 'Proc-Type:' debug3: key_read: missing
> keytype debug2: key_type_from_name:
> unknown key type 'DEK-Info:' debug3:
> key_read: missing keytype debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug3:
> key_read: missing whitespace debug2:
> key_type_from_name: unknown key type
> '-----END' debug3: key_read: missing
> keytype debug1: identity file
> /home/keven/.ssh/id_rsa type 1 debug1:
> Checking blacklist file
> /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file
> /etc/ssh/blacklist.RSA-2048 debug1:
> Remote protocol version 2.0, remote
> software version OpenSSH_4.7 debug1:
> match: OpenSSH_4.7 pat OpenSSH_4*
> debug1: Enabling compatibility mode
> for protocol 2.0 debug1: Local version
> string SSH-2.0-OpenSSH_5.1p1
> Debian-5ubuntu1 debug2: fd 3 setting
> O_NONBLOCK debug1: SSH2_MSG_KEXINIT
> sent debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit:
> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit:
> ssh-rsa,ssh-dss debug2:
> kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit:
> none,[email protected],zlib debug2:
> kex_parse_kexinit:
> none,[email protected],zlib debug2:
> kex_parse_kexinit: debug2:
> kex_parse_kexinit: debug2:
> kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit:
> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit:
> ssh-rsa,ssh-dss debug2:
> kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit:
> none,[email protected] debug2:
> kex_parse_kexinit:
> none,[email protected] debug2:
> kex_parse_kexinit: debug2:
> kex_parse_kexinit: debug2:
> kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: mac_setup: found hmac-md5
> debug1: kex: server->client aes128-cbc
> hmac-md5 none debug2: mac_setup: found
> hmac-md5 debug1: kex: client->server
> aes128-cbc hmac-md5 none debug1:
> SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192)
> sent debug1: expecting
> SSH2_MSG_KEX_DH_GEX_GROUP debug2:
> dh_gen_key: priv key bits set: 128/256
> debug2: bits set: 508/1024 debug1:
> SSH2_MSG_KEX_DH_GEX_INIT sent debug1:
> expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug3: check_host_in_hostfile:
> filename /root/.ssh/known_hosts
> debug3: check_host_in_hostfile: match
> line 1 debug3: check_host_in_hostfile:
> filename /root/.ssh/known_hosts
> debug3: check_host_in_hostfile: match
> line 2 debug1: Host
> 'planetlab1.csee.usf.edu' is known and
> matches the RSA host key. debug1:
> Found key in /root/.ssh/known_hosts:1
> debug2: bits set: 535/1024 debug1:
> ssh_rsa_verify: signature correct
> debug2: kex_derive_keys debug2:
> set_newkeys: mode 1 debug1:
> SSH2_MSG_NEWKEYS sent debug1:
> expecting SSH2_MSG_NEWKEYS debug2:
> set_newkeys: mode 0 debug1:
> SSH2_MSG_NEWKEYS received debug1:
> SSH2_MSG_SERVICE_REQUEST sent debug2:
> service_accept: ssh-userauth debug1:
> SSH2_MSG_SERVICE_ACCEPT received
> debug2: key: /home/keven/.ssh/id_rsa
> (0xb80c9878) debug1: Authentications
> that can continue:
> publickey,keyboard-interactive debug3:
> start over, passed a different list
> publickey,keyboard-interactive debug3:
> preferred
> gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
> debug3: authmethod_lookup publickey
> debug3: remaining preferred:
> keyboard-interactive,password debug3:
> authmethod_is_enabled publickey
> debug1: Next authentication method:
> publickey debug1: Offering public key:
> /home/keven/.ssh/id_rsa debug3:
> send_pubkey_test debug2: we sent a
> publickey packet, wait for reply
> debug1: Authentications that can
> continue:
> publickey,keyboard-interactive debug2:
> we did not send a packet, disable
> method debug3: authmethod_lookup
> keyboard-interactive debug3: remaining
> preferred: password debug3:
> authmethod_is_enabled
> keyboard-interactive debug1: Next
> authentication method:
> keyboard-interactive debug2:
> userauth_kbdint debug2: we sent a
> keyboard-interactive packet, wait for
> reply debug1: Authentications that can
> continue:
> publickey,keyboard-interactive debug3:
> userauth_kbdint: disable: no
> info_req_seen debug2: we did not send
> a packet, disable method debug1: No
> more authentication methods to try.
> Permission denied
> (publickey,keyboard-interactive).
«OpenSSH for Windows» version
7.7.2.1
Server OperatingSystem
Windows Server 2019 Datacenter
Client OperatingSystem
Windows 10 Pro
What is failing
I can connect to the Windows Server 2019 (domain joined)
- from Windows 10 client via Internet
ssh -v username@ipDOES NOT WORK - from Windows 10 using WinSCP.exe WORKS
- from Ubuntu WSL
ssh jsw@fqdnWORKS - locally in the server
ssh username@localhostWORKS - from Ubuntu
ssh jsw@fqdnWORKS
Expected output
Successful login
Actual output
username@ip: Permission denied (publickey,password,keyboard-interactive).
The only client that fails is the ssh.exe from Windows 10. Can anyone help me find out why? Here’s the ssh log:
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
debug1: Reading configuration data C:\\Users\\yooak/.ssh/config
debug1: C:\\Users\\yooak/.ssh/config line 1: Applying options for *
debug1: Connecting to 40.118.103.34 [40.118.103.34] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\yooak/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\yooak/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\yooak/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\yooak/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\yooak/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\yooak/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\yooak/.ssh/id_ed25519 type 3
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\yooak/.ssh/id_ed25519-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\yooak/.ssh/id_xmss type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\yooak/.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_for_Windows_7.7
debug1: match: OpenSSH_for_Windows_7.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 40.118.103.34:22 as 'june'
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: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:yPNwoYDrXFsygNKZjuFjbOcpiV6UkXkq6KFeNCyJ7lg
debug1: Host '40.118.103.34' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\yooak/.ssh/known_hosts:38
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: 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,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:S3gDtopWHfXlLhUNWCc89/x4eXOXIZVsNd3rgtyLHk4 C:\\Users\\yooak/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: ED25519 SHA256:ZyLjH5uIMN14F/QkeOA2yFMM3J9CY87ytOybLQ2YbLw C:\\Users\\yooak/.ssh/id_ed25519
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: C:\\Users\\yooak/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\yooak/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\yooak/.ssh/id_xmss
debug1: No more authentication methods to try.
june@40.118.103.34: Permission denied (publickey,password,keyboard-interactive).
День добрый. Возник вопрос с авторизацией в Windows OpenSSH по ключу.
До этого несколько раз доводилось настраивать без ключей (только по паролю) и вроде бы все было ок.
В этот раз решил сделать авторизацию только по SSH-ключу и напоролся на Permission denied (publickey,keyboard-interactive).
Кратко о сервере:
Сервер — винда 10
Юзер — локальная учетная запись (с правами администратора)
Публичный ключ лежит в authorized_keys в дирректории пользователя (C:\Users\LocalUser\.ssh\authorized_keys).
Всевозможные перезапуски и перезагрузки были.
OpenSSH сервер установлен: (на всякий случай испробованы оба варианта)
1) Параметры -> Приложения -> Дополнительные компоненты -> Сервер OpenSSH
2) Через PowerShell согласно официальной инструкции
Поискав некоторые моменты из лога наткнулся на закрытую issue от 2017 года в которой было упомянуто, что
Windows inbox Beta version currently supports one key type (ed25519).
До этого использовал RSA-ключи и в логе мелькала информация о ключах в духе
debug1: identity file C:\\Users\\LocalUser/.ssh/id_rsa type 0
debug1: identity file C:\\Users\\LocalUser/.ssh/id_ed25519 type -1Под каждым из которых была строка о том что файл не найден.
После чтения той issue стал использовать ed25519-ключ, теперь стало так:
debug1: identity file C:\\Users\\LocalUser/.ssh/id_ed25519 type 3
debug3: Failed to open file:C:/Users/LocalUser/.ssh/id_ed25519-cert error:2
debug3: Failed to open file:C:/Users/LocalUser/.ssh/id_ed25519-cert.pub error:2
debug1: identity file C:\\Users\\LocalUser/.ssh/id_ed25519-cert type -1Собственно в конечном счете в логе мелькает (если я правильно понимаю) отправка ключа
debug1: Offering public key: C:\\Users\\LocalUser/.ssh/id_ed25519 ED25519 SHA256:xKMs9i1ZJyeQjvIY3jL2WIZnGNwOr6v/7QLUPu9t2Nw explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51Однако после него SSH пытается пройти авторизацию по другим включенным способам авторизации — если по паролю включена — спрашивает пароль (даже в случае когда ключ явно указан), если выключена — сразу Permission denied (publickey,keyboard-interactive).
Подскажите в чем проблема в этом случае?
Полный лог c клиента доступен на https://gist.github.com/NEK-RA/e3656f98ca7e1b6c4d7… (т.к. если вставить его напрямую тут, будет превышен лимит в 10 000 символов в тексте вопроса)
UPD: По той же ссылке добавлен и лог сервера с небольшим отличием — на текущий момент не было доступа к нужному устройству, поэтому ситуация продублирована в виртуальной машине.
I’m trying to build a git repo server with a windows remote. Here is my ssh server and local client building environment:
Server env
1. windows os
2. mysysgit installed
3. copssh installed
4. remote cloud server
client
1. centOS 7 on vmware
2. local pc
Here is my already taken actions.
1. generate a public-private key pair with ssh-keygen -t rsa on my centos client
2. add a git user named svccopssh in my remote windows server
3. copy my centos ~/.ssh/id_rsa.pub to the server folder d:/Users/svccopssh/.ssh, in which copssh reads public-ssh-key, and rename it as authorized_keys
4. run test:
ssh -vT svccopssh@remoteIP
The result comes out like this:
[is_january@localhost .ssh]$ ssh -vT [email protected]
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to 120.76.123.231 [120.76.123.231] port 22.
debug1: Connection established.
debug1: identity file /home/is_january/.ssh/id_rsa type 1
debug1: identity file /home/is_january/.ssh/id_rsa-cert type -1
debug1: identity file /home/is_january/.ssh/id_dsa type -1
debug1: identity file /home/is_january/.ssh/id_dsa-cert type -1
debug1: identity file /home/is_january/.ssh/id_ecdsa type -1
debug1: identity file /home/is_january/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/is_january/.ssh/id_ed25519 type -1
debug1: identity file /home/is_january/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.1
debug1: match: OpenSSH_7.1 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: kex: [email protected] need=20 dh_need=20
debug1: kex: [email protected] need=20 dh_need=20
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDS 26:95:35:2c:32:ad:46:14:94:5e:71:95:b7:f7:2d:aa
debug1: Host '120.76.123.231' is known and matches the ECDSA host key.
debug1: Found key in /home/is_january/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/is_january/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/is_january/.ssh/id_dsa
debug1: Trying private key: /home/is_january/.ssh/id_ecdsa
debug1: Trying private key: /home/is_january/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).
Any suggestions ? I am sure that the same public-key works well on github ssh-key
В этой статье мы настроим SSH аутентификацию в Windows по RSA или EdDSA ключам для безопасного доступа к удаленным компьютерам/серверам. Рассмотрим, как сгенерировать открытый и закрытый ключи (сертификаты) в Windows и настроить сервер OpenSSH в Windows 10/11 и Windows Server 2019/2022 для аутентификации по ключам (без паролей).
Аутентификация по SSH ключам широко используется в мире Linux, а в Windows этот функционал появился относительно недавно. Идея заключается в том, что на SSH сервере добавляется открытый ключ клиента и при подключении сервер проверяет наличие соответствующего закрытого ключа у клиента. Таким образом удаленный пользователь может аутентифицироваться в Windows без ввода пароля.
Содержание:
- Генерация SSH ключей на клиенте Windows
- Настройка OpenSSH в Windows для авторизации по ключам
- Вход по SSH ключу для локальных администраторов Windows
Генерация SSH ключей на клиенте Windows
На клиентском, компьютере, с которого вы будет подключаетесь к удалённому серверу Windows с OpenSSH, вам нужно сгенерировать пару ключей (открытый и закрытый). Закрытый ключ хранится на клиенте (не отдавайте его никому!), а открытый ключ нужно скопировать в файл authorized_keys на SSH сервере. Чтобы сгенерировать SSH ключи на клиенте Windows, вы должны установить клиент OpenSSH.
В Windows 10/11 и Windows Server 2019/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 авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).
Generating public/private ed25519 key pair. Enter file in which to save the key (C:\Users\myuser/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in C:\Users\myuser/.ssh/id_ed25519. Your public key has been saved in C:\Users\myuser/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:C2wXeCQSUcJyq0 myuser@computername The key's randomart image is: +--[ED25519 256]--+ | ..*O=..o. | +----[SHA256]-----+
Утилита ssh-keygen создаст каталог .ssh в профиле текущего пользователя Windows (%USERPROFILE%\.ssh) и сгенерирует 2 файла:
-
id_ed25519
– закрытый ключ (если вы сгенерировали ключ типа RSA, файл будет называться
id_rsa
) -
id_ed25519.pub
– публичный ключ (аналогичный RSA ключ называется
id_rsa.pub
)
После того, как ключи созданы, вы можете добавить закрытый ключ в службу SSH Agent, которая позволяет удобно управлять закрытыми ключами и использовать их для аутентификации.
SSH Agent может хранить закрытые ключи и предоставлять их в контексте безопасности текущего пользователя. Запустите службу ssh-agent и настройте автоматический запуск с помощью PowerShell команд управления службами:
Set-service ssh-agent StartupType ‘Automatic’
Start-Service ssh-agent
Добавьте ваш закрытый ключ в базу ssh-agent:
ssh-add "C:\Users\user\.ssh\id_ed25519"
Identity added: C:\Users\kbuldogov\.ssh\id_ed25519 (kbuldogov@computername)
Или так:
ssh-add.exe $ENV:UserProfile\.ssh\id_ed25519
Настройка OpenSSH в Windows для авторизации по ключам
SSH сервер (в этом примере это удаленный компьютер с Windows 11 и настроенной службой OpenSSH).
Скопируйте файл id_ed25519.pub в каталог .ssh профиля пользователя, под которым вы будете подключаться к SSH серверу. Например, у меня в Windows 11 создан пользователь user1, значит я должен скопировать ключ в файл C:\Users\user1\.ssh\authorized_keys.
В данном примере подразумевается, что user1 это обычная учетная запись пользователя без прав локального администратора на компьютере с сервером SSH.
Если каталог .ssh в профиле отсутствует, его нужно создать вручную.
Можно скопировать ключ на SSH сервер с клиента с помощью SCP:
scp C:\Users\youruser\.ssh\id_rsa.pub [email protected]:c:\users\user1\.ssh\authorized_keys
В один файл authorized_keys можно добавить несколько открытых ключей.
По умолчанию в OpenSSH сервере в Windows отключена аутентификация по ключам. Вы можете проверить это в конфигурационном файле sshd_config. Проще всего получить список разрешенных способов аутентификации в OpenSSH с помощью такой PowerShell команды (Select-String используется как аналог grep в PowerShell):
cat "C:\ProgramData\ssh\sshd_config"| Select-String "Authentication"
#PubkeyAuthentication yes #HostbasedAuthentication no # HostbasedAuthentication PasswordAuthentication yes #GSSAPIAuthentication no
В этом примере строка PubkeyAuthentication закомментирована, значит этот способ аутентификации отключен.
Откройте файл sshd_config с помощью блокнота, раскоментируйте строку:
Notepad C:\ProgramData\ssh\sshd_config
PubkeyAuthentication yes
Также в конфигурационном файле sshd_config придется отключить режим StrictModes. По умолчанию этот режим включен и запрещает аутентификацию по ключам, если закрытый и открытый ключ недостаточно защищены. Раскомментируйте строку
#StrictModes yes
, измените на
StrictModes no
.
Сохраните файл и перезапустите службу sshd:
Restart-Service sshd
Теперь вы можете подключиться к SSH серверу без ввода пароля пользователя. А если вы не задали пароль (passphrase) для закрытого ключа, вы сразу автоматически подключитесь к вашему удаленному серверу Windows.
Для подключения через SSH к удаленному хосту используется следующая команда:
ssh (username)@(имя или IP адрес SSH сервера)
Например,
ssh [email protected]
Это означает, что вы хотите подключиться к удаленному SSH серверу с адресом 192.168.1.90 под учетной записью admin. Служба SSH Agent автоматически попытается использовать для авторизации сохраненный ранее закрытый ключ.
- Если вы не хотите использовать ssh-agent для управления ключами, вы можете указать путь к закрытому ключу, который нужно использовать для SSH аутентификации:
ssh [email protected] -i "C:\Users\user\.ssh\id_ed25519" - Для подключения с помощью учетной записи пользователя из домена Active Directory используется формат:
ssh kbu[email protected]@168.1.90 -i <private_key_absolute_path>
При первом подключении нужно добавить отпечаток ключа SSH сервера в доверенные. Наберите yes -> Enter.
The authenticity of host '192.168.1.90 (192.168.1.90)' can't be established. ECDSA key fingerprint is SHA256:LNMJTbTS0EmrsGYTHB3Aa3Tisp+7fvHwZHbTA900ofw. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Информацию по аутентификации в Windows с помощью SSH ключей можно найти в журнале события. В современных версиях OpenSSH логи пишутся не в текстовые файлы, а в отдельный журнал Event Viewer (Application and services logs -> OpenSSH -> Operational).
При успешном подключении с помощью ключа в журнале появится событие:
EventID 4 sshd: Accepted publickey for locadm from 192.168.14.1 port 55772 ssh2: ED25519 SHA256:FEHDWM/J74FbIzCCoJNbh14phS67kQgh7k8UrKPSvCM
Если вы не смогли подключиться к вашему SSH серверу по RSA ключу, и у вас все равно запрашивается пароль, скорее всего пользователь, под которым вы подключаетесь, входит в группу локальных администраторов сервера (SID группы S-1-5-32-544). Об этом далее.
Вход по SSH ключу для локальных администраторов Windows
В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.
В первую очередь, вместо ключа authorized_keys в профиле пользователя нужно использовать файл с ключами C:\ProgramData\ssh\administrators_authorized_keys. Вам нужно добавить ваш ключ в этот текстовый файл (в целях безопасности права на этот файл должны быть только у группы Administrators и SYSTEM).
Вы можете изменить NTFS права на файл с помощью:
- утилиты icacls:
icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F - или с помощью PowerShell командлетов get-acl и set-acl:
get-acl "$env:programdata\ssh\ssh_host_rsa_key" | set-acl "$env:programdata\ssh\administrators_authorized_keys"
После этого SSH аутентификация по ключам работает даже при отключенном режиме StrictModes
alert]Чтобы использовать ключ authorized_keys из профиля пользователя, и не переносить данные открытого ключа в файл administrators_authorized_keys, вы можете закомментировать строку в файле конфигурации OpenSSH (C:\ProgramData\ssh\sshd_config).
Закомментируйте строки:
#Match Group administrators # AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
Дополнительно в файле sshd_config вы можете запретить SSH подключение по паролю по паролю:
PasswordAuthentication no
После сохранения изменений в файле sshd_config не забудьте перезапустить службу sshd.
restart-service sshd
Если вы установили PasswordAuthentication no, и некорректно настроите аутентификацию по ключам, то при подключении по ssh будет появляться ошибка:
[email protected]: Permission denied (publickey,keyboard-interactive).
В OpenSSH на Linux доступна опция PermitRootLogin, позволяющая ограничить доступ к SSH серверу под аккаунтом root. В Windows OpenSSH эта директива не доступна и для ограничения доступа администраторов нужно использовать параметр DenyGroups.
Итак, вы настроили SSH аутентификацию в Windows по открытому RSA-ключу (сертификату). Теперь вы можете использовать такой способ аутентификации для безопасного доступа к удаленным северам, автоматического поднятия проброса портов в SSH туннеле, запуска скриптов и других задачах автоматизации.