Win get ssh key

Как сгенерировать ключ SSH в Windows 10

Генерация ключей SSH в среде Windows раньше была сложным процессом, требующим установки сторонних инструментов. После обновления Windows 10 апреля 2018 года, Windows поставляется с предустановленным клиентом OpenSSH, что означает, что вы можете использовать ssh-keygen для генерации ключей SSH. Давайте разберем, как сгенерировать SHH ключ в Windows 10.

Проверка OpenSSH в Windows 10

Нужно убедиться, что OpenSSH установлен на вашем компьютере, если вы обновили более раннюю версию Windows 10, вам может потребоваться включить ее вручную. Для этого:

• Откройте параметры «Параметры» > «Приложения«. Затем справа нажмите на ссылку «Дополнительные возможности«.
• Если вы не видите «Клиент OpenSSH» в появившемся списке, нажмите кнопку «Добавить компонент» и установите его из списка.

Сгенерировать SHH в Windows 10

Откройте командную строку и введите ssh-keygen

1. Вам будет предложено подтвердить место сохранения (можете изменить путь). Нажмите Enetr и место будет по умолчанию.
2. Далее вам будет предложено задать пароль (ключевую фразу) к ключу, он не отображается при вводе, но вводится. Можно без пароля, нажать сразу Enter.
3. Подтверждение выше заданного пароля.

Источник

Key-based authentication in OpenSSH for Windows

Applies to Windows Server 2022, Windows Server 2019, Windows 10 (build 1809 and later)

Most authentication in Windows environments is done with a username-password pair, which works well for systems that share a common domain. When working across domains, such as between on-premises and cloud-hosted systems, it becomes vulnerable to brute force intrusions.

By comparison, Linux environments commonly use public-key/private-key pairs to drive authentication that doesn’t require the use of guessable passwords. OpenSSH includes tools to help support key based authentication, specifically:

• ssh-keygen for generating secure keys
• ssh-agent and ssh-add for securely storing private keys
• scp and sftp to securely copy public key files during initial use of a server

This document provides an overview of how to use these tools on Windows to begin using key-based authentication with SSH. If you’re unfamiliar with SSH key management, we strongly recommend you review NIST document IR 7966 titled «Security of Interactive and Automated Access Management Using Secure Shell (SSH)».

About key pairs

Key pairs refer to the public and private key files that are used by certain authentication protocols.

SSH public key authentication uses asymmetric cryptographic algorithms to generate two key files – one «private» and the other «public». The private key files are the equivalent of a password, and should stay protected under all circumstances. If someone acquires your private key, they can sign in as you to any SSH server you have access to. The public key is what is placed on the SSH server, and may be shared without compromising the private key.

Key based authentication enables the SSH server and client to compare the public key for a user name provided against the private key. If the server-side public key can’t be validated against the client-side private key, authentication fails.

Multi-factor authentication may be implemented with key pairs by entering a passphrase when the key pair is generated (see user key generation below). The user will be prompted for the passphrase during authentication. The passphrase is used along with the presence of the private key on the SSH client to authenticate the user.

A remote session opened via key based authentication does not have associated user credentials and hence is not capable of outbound authentication as the user, this is by design.

Host key generation

Public keys have specific ACL requirements that, on Windows, equate to only allowing access to administrators and System. On first use of sshd, the key pair for the host will be automatically generated.

You need to have OpenSSH Server installed first. Please see Getting started with OpenSSH.

By default the sshd service is set to start manually. To start it each time the server is rebooted, run the following commands from an elevated PowerShell prompt on your server:

Since there’s no user associated with the sshd service, the host keys are stored under C:\ProgramData\ssh.

User key generation

To use key-based authentication, you first need to generate public/private key pairs for your client. ssh-keygen.exe is used to generate key files and the algorithms DSA, RSA, ECDSA, or Ed25519 can be specified. If no algorithm is specified, RSA is used. A strong algorithm and key length should be used, such as Ed25519 in this example.

To generate key files using the Ed25519 algorithm, run the following command from a PowerShell or cmd prompt on your client:

The output from the command should display the following output (where «username» is replaced by your username):

You can press Enter to accept the default, or specify a path and/or filename where you would like your keys to be generated. At this point, you’ll be prompted to use a passphrase to encrypt your private key files. The passphrase can be empty but it’s not recommended. The passphrase works with the key file to provide two-factor authentication. For this example, we’re leaving the passphrase empty.

Now you have a public/private ed25519 key pair in the location specified. The .pub files are public keys, and files without an extension are private keys:

Remember that private key files are the equivalent of a password should be protected the same way you protect your password. Use ssh-agent to securely store the private keys within a Windows security context, associated with your Windows account. To start the ssh-agent service each time your computer is rebooted, and use ssh-add to store the private key run the following commands from an elevated PowerShell prompt on your server:

Once you’ve added the key to the ssh-agent on your client, the ssh-agent will automatically retrieve the local private key and pass it to your SSH client.

It is strongly recommended that you back up your private key to a secure location, then delete it from the local system, after adding it to ssh-agent. The private key cannot be retrieved from the agent providing a strong algorithm has been used, such as Ed25519 in this example. If you lose access to the private key, you will have to create a new key pair and update the public key on all systems you interact with.

Deploying the public key

To use the user key that was created above, the contents of your public key (\.ssh\id_ed25519.pub) needs to be placed on the server into a text file. The name and location of the file depends on whether the user account is a member of the local administrators group or a standard user account. The following sections cover both standard and administrative users.

Standard user

The contents of your public key (\.ssh\id_ed25519.pub) needs to be placed on the server into a text file called authorized_keys in C:\Users\username\.ssh\. You can copy your public key using the OpenSSH scp secure file-transfer utility, or using a PowerShell to write the key to the file.

The example below copies the public key to the server (where «username» is replaced by your username). You’ll need to use the password for the user account for the server initially.

Administrative user

The contents of your public key (\.ssh\id_ed25519.pub) needs to be placed on the server into a text file called administrators_authorized_keys in C:\ProgramData\ssh\. You can copy your public key using the OpenSSH scp secure file-transfer utility, or using a PowerShell to write the key to the file. The ACL on this file needs to be configured to only allow access to administrators and System.

The example below copies the public key to the server and configures the ACL (where «username» is replaced by your user name). You’ll need to use the password for the user account for the server initially.

This example shows the steps for creating the administrators_authorized_keys file. This only applies to administrator accounts and must be user instead of the per user file within the user’s profile location.

These steps complete the configuration required to use key-based authentication with OpenSSH on Windows. Once the example PowerShell commands have been run, the user can connect to the sshd host from any client that has the private key.

Источник

Настройка SSH аутентификации по ключам в Windows

В этой статье мы настроим SSH аутентификацию в Windows по RSA или EdDSA ключам для безопасного доступа к удаленным компьютерам/серверам. Рассмотрим, как сгенерировать открытый и закрытый ключи (сертификаты) в Windows и настроить сервер OpenSSH в Windows 10/11 и Windows Server 2019/2022 для аутентификации по ключам (без паролей).

Аутентификация по SSH ключам широко используется в мире Linux, а в 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

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

ssh-keygen -t ed25519

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

Утилита 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:

Или так:

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

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

Скопируйте файл id_ed25519.pub в каталог .ssh профиля пользователя, под которым вы будете подключаться к SSH серверу. Например, у меня в Windows 11 создан пользователь user1, значит я должен скопировать ключ в файл C:\Users\user1\.ssh\authorized_keys.

Если каталог .ssh в профиле отсутствует, его нужно создать вручную.

Можно скопировать ключ на SSH сервер с клиента с помощью SCP:

scp C:\Users\youruser\.ssh\id_rsa.pub admin@192.168.1.90:c:\users\user1\.ssh\authorized_keys

По умолчанию в OpenSSH сервере в Windows отключена аутентификация по ключам. Вы можете проверить это в конфигурационном файле sshd_config. Проще всего получить список разрешенных способов аутентификации в OpenSSH с помощью такой PowerShell команды (Select-String используется как аналог grep в PowerShell):

cat «C:\ProgramData\ssh\sshd_config»| Select-String «Authentication»

В этом примере строка PubkeyAuthentication закомментирована, значит этот способ аутентификации отключен.

Откройте файл sshd_config с помощью блокнота, раскоментируйте строку:

Также в конфигурационном файле sshd_config придется отключить режим StrictModes. По умолчанию этот режим включен и запрещает аутентификацию по ключам, если закрытый и открытый ключ недостаточно защищены. Раскомментируйте строку #StrictModes yes , измените на StrictModes no .

Сохраните файл и перезапустите службу sshd:

Теперь вы можете подключиться к SSH серверу без ввода пароля пользователя. А если вы не задали пароль (passphrase) для закрытого ключа, вы сразу автоматически подключитесь к вашему удаленному серверу Windows.

Для подключения через SSH к удаленному хосту используется следующая команда:

ssh (username)@(имя или IP адрес SSH сервера)

Это означает, что вы хотите подключиться к удаленному SSH серверу с адресом 192.168.1.90 под учетной записью admin. Служба SSH Agent автоматически попытается использовать для авторизации сохраненный ранее закрытый ключ.

• Если вы не хотите использовать ssh-agent для управления ключами, вы можете указать путь к закрытому ключу, который нужно использовать для SSH аутентификации: ssh user1@192.168.14.145 -i «C:\Users\user\.ssh\id_ed25519»
• Для подключения с помощью учетной записи пользователя из домена Active Directory используется формат: ssh kbuldogov@winitpro.ru@168.1.90 -i

При первом подключении нужно добавить отпечаток ключа SSH сервера в доверенные. Наберите yes -> Enter.

Информацию по аутентификации в Windows с помощью SSH ключей можно найти в журнале события. В современных версиях OpenSSH логи пишутся не в текстовые файлы, а в отдельный журнал Event Viewer (Application and services logs -> OpenSSH -> Operational).

При успешном подключении с помощью ключа в журнале появится событие:

Если вы не смогли подключиться к вашему 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).

Дополнительно в файле sshd_config вы можете запретить SSH подключение по паролю по паролю:

После сохранения изменений в файле sshd_config не забудьте перезапустить службу sshd.

Если вы установили PasswordAuthentication no, и некорректно настроите аутентификацию по ключам, то при подключении по ssh будет появляться ошибка:

Итак, вы настроили SSH аутентификацию в Windows по открытому RSA-ключу (сертификату). Теперь вы можете использовать такой способ аутентификации для безопасного доступа к удаленным северам, автоматического поднятия проброса портов в SSH туннеле, запуска скриптов и других задачах автоматизации.

Спасибо! Первая рабочая статья -_ stackoverflow.com уже весь на эту тему перечитал).

debug1: Found key in C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/known_hosts:9
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_rsa (000002372A7B17D0), agent
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_dsa (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_ecdsa (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_ed25519 (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_xmss (0000000000000000)
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug2: service_accept: ssh-userauth
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:5U76PQzmZJ7xce9TDvyt1P/sqNCX/GHOZSLk3TR3x1o C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_dsa

Можете подсказать что не так?

Какую команду используете для SSH подключения? Ключ добавлен в ssh-agent?
Попробуйте указать путь к вашему файлу с закрытым ключом вручную:
ssh root@192.168.1.90 -i «C:\Users\user1\.ssh\id_rsa»

При генерации ключа не нашел файлы в профиле пользователя. Они были в «C:\Windows\System32»

Скорее всего вы запускали cmd\powershell.exe в режиме administrator, поэтому путь по-умолчанию был c:\windows\system32

А как это работает, если сервер на Linux, а клиент на Windows?

Да, все аналогично. Только в linux другое место хранения ключей (в зависимости от дистрибутива)

Ну наконец то получилось по ssh ключу подключиться. Мне нужно было настроить SFTP на Windows 10. Имеются 3 компа, на первом Windows 10 с openssh server и запущенным процессом sftp-server.exe, на втором компе клиенте тоже Windows 10 установил openssh client, сгенерировал публичный и приватный ключ, публичный скопировал на первый комп с Windows 10 где установлен openssh server, переименовал его из id_rsa.pub в authorized_keys. Затем на втором компе клиенте нужно установить PuTTY Key Generator и сконвертировать приватный ключ id_rsa в id_rsa.ppk это нужно чтобы подключиться по SFTP через WinSCP или FileZilla client к серверу openssh. Проблема была в том что всё равно просил пароль от учётной записи администратора от первого компа на сервере. После того как прописал «PubkeyAuthentication yes» и «PasswordAuthentication no» затем «StrictModes no» и закомментировал «# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys» стало заходить без пароля. Есть ещё вопрос. Третий комп это ноутбук с Kubuntu, установил FileZilla client, уже имеется каталог по адресу /home/sergei/.ssh/ в этот каталог скопировал файл id_rsa.ppk со второго компа, то есть с Windows 10. При подключении FileZilla client выбираю протокол SFTP всё как положено, указываю файл с приватным ключом /home/sergei/.ssh/id_rsa.ppk и подключаюсь без ввода пароля, всё работает. Но я так понимаю что это неправильно? На Kubuntu тоже надо генерировать ключи приватный и публичный? И где тогда размещать новый публичный ключ на сервере, если на нём уже есть C:\Users\Sergei\.ssh\authorized_keys

В файле authorized_keys можно указывать несколько ключей. Просто скопируйте значение второго ключа с новой строки и сохраните файл.

Всё теперь разобрался, Спасибо.

Модуль OpenSSHUtis установился только так

Install-Module -Name OpenSSHUtils -Force -RequiredVersion 1.0.0.1 -SkipPublisherCheck

Проделал все операции — но всё равно пишет Permission denied (publickey,keyboard-interactive)
Ключ прописал, строки комментировал. Куда ещё посмотреть?:

Обновил статью. Самый простой вариант — посмотрите в сторону директивы StrictModes no
Вы подключаетесь под admin пользователем?

да. В итоге с помощью танцев с бубнами и такой то матери оно завелось. Но к примеру если хочешь посмотреть в AD через ssh ТО нужно всё равно вводить логин и пароль для доступа к домену. Оно не умеет использовать ту же учётную запись с которой заходишь в ssh

Изначально нашел ссылку
https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement
Не работает — хоть ты тресни) Навозился…
В итоге проблему решило указание имени без домена.
То есть вариант домен\юзер требует пароль.
Указал просто юзер — получилось)

Подскажите пожалуйста, настроил SSH и спокойно подключаюсь через с андроида JuiseSSH , ввожу пару user@имякомпа , ввожу пароль заходит в терминал PowerShell. Но это всё работает лишь на домашнем вайфае, как мне сделать так чтобы я вне своей сети мог подключиться к своему компу?
И ещё когда ввожу root@192. *.*.* (ip адрес своего компа) просит пароль, все свои пароли перепробовал не подключается, где хранится этот пароль не подскажите директорию?
Простите если что не так я только учусь настраивать удалённые подключения (любитель) для своего компа с телефона.

После того как с Juise_SSH подключился root@192.*.*.* попросило подтвердить ключ(pub), подтвердил , но запросило пароль 🙁

Так ты сначала создай его для root. Вот же sudo passwd root _https://losst.ru/parol-root-v-ubuntu

ssh ключи можно хранить и брать из AD
_https://www.saotn.org/retrieve-ssh-public-key-from-active-directory-for-ssh-authentication/
_https://access.redhat.com/solutions/5353351

В Linux можно ограничить выполнение каких-то команд при подключении по SSH с аутентификацией через сертификат. Для этого
В файл authorized_keys перед самим сертификатом добавить разрешающую команду:
command=»top» ssh-rsa your_thumbprint

Источник