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

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

Аутентификация по в SSH ключам широко используется в мире Linux, а в Windows этот функционал появился относительно недавно. Идея заключается в том, что на SSH сервере добавляется открытый ключ клиента и при подключении сервер проверяет наличие соответствующего закрытого ключа у клиента.

Генерация RSA ключей на клиенте Windows

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

В Windows 10 1809 и Windows Server 2019 клиент OpenSSH устанавливается как отдельный встроенный компонент:

Add-WindowsCapability -Online -Name OpenSSH.Client

Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару RSA 2048 ключей с помощью команды:

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

Утилита ssh-keygen создаст каталог .ssh в профиле текущего пользователя Windows (C:\Users\your_username) и поместит в него 2 файла:

• id_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 10 1903 и настроенной службой OpenSSH).

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

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

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

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

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

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

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

ssh admin@192.168.1.90 -i «C:\Users\youruser\.ssh\id_rsa»

Если вы не смогли подключиться к вашему SSH серверу по RSA ключу, и у вас все равно запрашивается пароль, скорее всего пользователь, под которым вы подключаетесь, входит в группу локальных администраторов сервера (SID группы S-1-5-32-544). Об этом далее.

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

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

В первую очередь, вместо ключа authorized_keys в профиле пользователя нужно использовать файл с ключами C:\ProgramData\ssh\administrators_authorized_keys. Вам нужно добавить ваш ключ в этот текстовый файл (в целях безопасности права на этот файл должны быть только у группы Administrators и SYSTEM).

Чтобы использовать ключ authorized_keys из профиля пользователя, и не переносить данные открытого ключа в файл administrators_authorized_keys, вы можете закомментировать строку в файле конфигурации OpenSSH («C:\ProgramData\ssh\sshd_config«).

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

И запретить доступ по паролю:

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

Еще один небольшой нюанс. В старых версиях OpenSSH нужно было предоставить права службе NT Service\sshd на чтение ключа authorized_keys.

Для этого нужно выполнить одно из следующих действий:

• Установить модуль OpenSSHUtils: Install-Module -Force OpenSSHUtils -Scope AllUsers . Для изменения прав на файл нужно выполнить команду: Repair-AuthorizedKeyPermission -FilePath C:\Users\admin\.ssh\authorized_keys ;
• Измените NTFS права на файл с помощью модуля NTFSSecurity или icacls;
• Либо вы можете в конфигурационном файле sshd_config отключить режим StrictModes. По умолчанию этот режим включен и запрещает аутентификацию по ключам, если закрытый и открытый ключ недостаточно защищены. Раскомментируйте строку #StrictModes yes , измените на StrictModes no .

Итак, вы настроили 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 можно указывать несколько ключей. Просто скопируйте значение второго ключа с новой строки и сохраните файл.

Удаленное взаимодействие с PowerShell через SSH PowerShell remoting over SSH

Обзор Overview

Функция удаленного взаимодействия PowerShell обычно использует WinRM для согласования соединения и передачи данных. PowerShell remoting normally uses WinRM for connection negotiation and data transport. Теперь протокол SSH доступен на платформах Linux и Windows, что позволяет осуществлять многоплатформенное удаленное взаимодействие с PowerShell. SSH is now available for Linux and Windows platforms and allows true multiplatform PowerShell remoting.

Служба удаленного управления Windows обеспечивает надежную модель поддержки удаленных сеансов PowerShell. WinRM provides a robust hosting model for PowerShell remote sessions. Удаленное взаимодействие по протоколу SSH сейчас не поддерживает настройку удаленных конечных точек и функцию JEA (Just Enough Administration). SSH-based remoting doesn’t currently support remote endpoint configuration and Just Enough Administration (JEA).

Удаленное взаимодействие по SSH позволяет осуществлять базовое удаленное взаимодействие между компьютерами с Windows и Linux в рамках сеансов PowerShell. SSH remoting lets you do basic PowerShell session remoting between Windows and Linux computers. Функция удаленного взаимодействия по SSH создает хост-процесс PowerShell на целевом компьютере в качестве подсистемы SSH. SSH remoting creates a PowerShell host process on the target computer as an SSH subsystem. Со временем для поддержки настройки удаленных конечных точек и функции JEA мы реализуем общую модель размещения, похожую на службе удаленного управления Windows. Eventually we’ll implement a general hosting model, similar to WinRM, to support endpoint configuration and JEA.

Командлеты New-PSSession , Enter-PSSession и Invoke-Command теперь имеют набор новых параметров для поддержки этой возможности удаленного взаимодействия. The New-PSSession , Enter-PSSession , and Invoke-Command cmdlets now have a new parameter set to support this new remoting connection.

Чтобы создать удаленный сеанс, укажите целевой компьютер с помощью параметра HostName и имя пользователя с помощью параметра UserName. To create a remote session, you specify the target computer with the HostName parameter and provide the user name with UserName. При интерактивном выполнении командлетов отображается запрос на ввод пароля. When running the cmdlets interactively, you’re prompted for a password. Вы также можете использовать проверку подлинности ключа SSH с помощью файла закрытого ключа с параметром KeyFilePath. You can also use SSH key authentication using a private key file with the KeyFilePath parameter. Способ создания ключей для проверки подлинности по протоколу SSH зависит от платформы. Creating keys for SSH authentication varies by platform.

Общие сведения об установке General setup information

PowerShell 6 или более поздней версии, и на всех компьютерах должен быть установлен SSH. PowerShell 6 or higher, and SSH must be installed on all computers. Установите клиент ( ssh.exe ) и сервер ( sshd.exe ) SSH, чтобы осуществлять удаленное взаимодействие между компьютерами. Install both the SSH client ( ssh.exe ) and server ( sshd.exe ) so that you can remote to and from the computers. Решение OpenSSH для Windows теперь доступно в Windows 10 сборки 1809 и Windows Server 2019. OpenSSH for Windows is now available in Windows 10 build 1809 and Windows Server 2019. Дополнительные сведения см. в статье Управление Windows через OpenSSH. For more information, see Manage Windows with OpenSSH. В Linux нужно реализовать поддержку SSH (включая установку сервера sshd) в соответствии с используемой платформой. For Linux, install SSH, including sshd server, that’s appropriate for your platform. Также для поддержки удаленного взаимодействия по SSH нужно установить PowerShell с сайта GitHub. You also need to install PowerShell from GitHub to get the SSH remoting feature. Для сервера SSH нужно настроить возможность создать подсистему SSH для размещения процесса PowerShell на удаленном компьютере. The SSH server must be configured to create an SSH subsystem to host a PowerShell process on the remote computer. Также нужно активировать проверку подлинности на основе пароля или ключа. And, you must enable password or key-based authentication.

Настройка на компьютере с Windows Set up on a Windows computer

Установите последнюю версию PowerShell. Install the latest version of PowerShell. Дополнительные сведения см. в статье Установка PowerShell Core в Windows. For more information, see Installing PowerShell Core on Windows.

Чтобы убедиться, что в PowerShell есть поддержка удаленного взаимодействия SSH, перечислите наборы параметров New-PSSession . You can confirm that PowerShell has SSH remoting support by listing the New-PSSession parameter sets. Обратите внимание на наличие имен наборов параметров, начинающихся с SSH. You’ll notice there are parameter set names that begin with SSH. К этим наборам параметров относятся параметры SSH. Those parameter sets include SSH parameters.

Установите последнюю версию Win32 OpenSSH. Install the latest Win32 OpenSSH. Инструкции по установке см. в разделе Начало работы с OpenSSH. For installation instructions, see Getting started with OpenSSH.

Если вы хотите задать PowerShell в качестве оболочки по умолчанию для OpenSSH, см. раздел Настройка Windows для OpenSSH. If you want to set PowerShell as the default shell for OpenSSH, see Configuring Windows for OpenSSH.

Измените файл sshd_config , расположенный в $env:ProgramData\ssh . Edit the sshd_config file located at $env:ProgramData\ssh .

Включите проверку подлинности с помощью пароля: Make sure password authentication is enabled:

Создайте подсистему SSH, в которой размещается процесс PowerShell на удаленном компьютере: Create the SSH subsystem that hosts a PowerShell process on the remote computer:

Расположение исполняемого файла PowerShell по умолчанию — c:/progra

1/powershell/7/pwsh.exe . The default location of the PowerShell executable is c:/progra

1/powershell/7/pwsh.exe . Расположение может различаться в зависимости от способа установки PowerShell. The location can vary depending on how you installed PowerShell.

Необходимо использовать краткое имя 8.3 для всех путей к файлам, содержащим пробелы. You must use the 8.3 short name for any file paths that contain spaces. В OpenSSH для Windows обнаружена ошибка, блокирующая работу пробелов в путях к исполняемым файлам подсистемы. There’s a bug in OpenSSH for Windows that prevents spaces from working in subsystem executable paths. См. дополнительные сведения на сайте GitHub. For more information, see this GitHub issue.

Обычно краткое имя 8.3 для папки Program Files в Windows — это Progra

1 . The 8.3 short name for the Program Files folder in Windows is usually Progra

1 . Тем не менее для проверки можно использовать следующую команду: However, you can use the following command to make sure:

При необходимости включите проверку подлинности на основе ключа: Optionally, enable key authentication:

Дополнительные сведения см. в статье Управление ключами OpenSSH. For more information, see Managing OpenSSH Keys.

Перезапустите службу sshd. Restart the sshd service.

Добавьте путь установки OpenSSH в свою переменную среды Path. Add the path where OpenSSH is installed to your Path environment variable. Например, C:\Program Files\OpenSSH\ . For example, C:\Program Files\OpenSSH\ . Это позволит найти файл ssh.exe . This entry allows for the ssh.exe to be found.

Настройка на компьютере с Ubuntu 16.04 Linux Set up on an Ubuntu 16.04 Linux computer

Установите последнюю версию PowerShell, см. раздел Установка PowerShell Core в Linux. Install the latest version of PowerShell, see Installing PowerShell Core on Linux.

Измените файл sshd_config в расположении /etc/ssh . Edit the sshd_config file at location /etc/ssh .

Включите проверку подлинности с помощью пароля: Make sure password authentication is enabled:

При необходимости включите проверку подлинности на основе ключа: Optionally, enable key authentication:

Дополнительные сведения о создании ключей SSH в Ubuntu см. на странице справки по ssh-keygen. For more information about creating SSH keys on Ubuntu, see the manpage for ssh-keygen.

Добавьте запись подсистемы PowerShell: Add a PowerShell subsystem entry:

Расположение исполняемого файла PowerShell по умолчанию — /usr/bin/pwsh . The default location of the PowerShell executable is /usr/bin/pwsh . Расположение может различаться в зависимости от способа установки PowerShell. The location can vary depending on how you installed PowerShell.

При необходимости включите проверку подлинности на основе ключа: Optionally, enable key authentication:

Перезапустите службу ssh. Restart the ssh service.

Настройка на компьютере с macOS Set up on a macOS computer

Установите последнюю версию PowerShell. Install the latest version of PowerShell. Дополнительные сведения см. в статье Установка PowerShell Core в macOS. For more information, Installing PowerShell Core on macOS.

Убедитесь, что удаленное взаимодействие SSH включено, выполните следующие действия: Make sure SSH Remoting is enabled by following these steps:

1. Откройте среду System Preferences . Open System Preferences .
2. Щелкните Sharing . Click on Sharing .
3. Установите флажок Remote Login , чтобы задать Remote Login: On . Check Remote Login to set Remote Login: On .
4. Разрешите доступ соответствующим пользователям. Allow access to the appropriate users.

Измените файл sshd_config в расположении /private/etc/ssh/sshd_config . Edit the sshd_config file at location /private/etc/ssh/sshd_config .

Используйте текстовый редактор, например nano: Use a text editor such as nano:

Включите проверку подлинности с помощью пароля: Make sure password authentication is enabled:

Добавьте запись подсистемы PowerShell: Add a PowerShell subsystem entry:

Расположение исполняемого файла PowerShell по умолчанию — /usr/local/bin/pwsh . The default location of the PowerShell executable is /usr/local/bin/pwsh . Расположение может различаться в зависимости от способа установки PowerShell. The location can vary depending on how you installed PowerShell.

При необходимости включите проверку подлинности на основе ключа: Optionally, enable key authentication:

Перезапустите службу sshd. Restart the sshd service.

Аутентификация Authentication

При удаленном взаимодействии с PowerShell через SSH используется обмен данными для проверки подлинности между клиентом SSH и службой SSH. Схемы проверки подлинности в его рамках не реализуются. PowerShell remoting over SSH relies on the authentication exchange between the SSH client and SSH service and doesn’t implement any authentication schemes itself. Это означает, что любые настроенные схемы проверки подлинности, включая многофакторную проверку подлинности, обрабатываются протоколом SSH независимо от PowerShell. The result is that any configured authentication schemes including multi-factor authentication are handled by SSH and independent of PowerShell. Например, в службе SSH можно настроить обязательное применение проверки подлинности на основе открытых ключей, а также разовых паролей для усиления безопасности. For example, you can configure the SSH service to require public key authentication and a one-time password for added security. Настройка многофакторной проверки подлинности выходит за рамки настоящего документа. Configuration of multi-factor authentication is outside the scope of this documentation. Сведения о том, как правильно настроить многофакторную проверку подлинности и проверить ее работу вне PowerShell, прежде чем пытаться использовать ее для удаленного взаимодействия с PowerShell, см. в документации по SSH. Refer to documentation for SSH on how to correctly configure multi-factor authentication and validate it works outside of PowerShell before attempting to use it with PowerShell remoting.

Пользователи сохраняют те же привилегии в удаленных сеансах. Users retain the same privileges in remote sessions. Это означает, что администраторы имеют доступ к оболочке с повышенными правами, а обычные пользователи — нет. Meaning, Administrators have access to an elevated shell, and normal users will not.

Пример удаленного взаимодействия PowerShell PowerShell remoting example

Проще всего проверить удаленное взаимодействие на одном компьютере. The easiest way to test remoting is to try it on a single computer. В этом примере мы создадим удаленный сеанс с одним и тем же компьютером Linux. In this example, we create a remote session back to the same Linux computer. Командлеты PowerShell мы выполняем в интерактивном режиме, поэтому мы увидим запрос от SSH на проверку удаленного компьютера, а также запрос на ввод пароля. We’re using PowerShell cmdlets interactively so we see prompts from SSH asking to verify the host computer and prompting for a password. Чтобы убедиться, что удаленное взаимодействие работает, те же операции можно выполнить на компьютере Windows. You can do the same thing on a Windows computer to ensure remoting is working. Затем установите удаленное подключение между компьютерами, изменив имя узла. Then, remote between computers by changing the host name.

Ограничения Limitations

Команда sudo не работает в рамках сеанса удаленного взаимодействия с компьютером Linux. The sudo command doesn’t work in a remote session to a Linux computer.

PSRemoting через SSH не поддерживает профили и не имеет доступа к $PROFILE . PSRemoting over SSH does not support Profiles and does not have access to $PROFILE . После входа в сеанс можно загрузить профиль с помощью вызова с точкой, указав полный путь к профилю. Once in a session, you can load a profile by dot sourcing the profile with the full filepath. Это не связано с профилями SSH. This is not related to SSH profiles. Вы можете настроить SSH-сервер для использования PowerShell в качестве оболочки по умолчанию и для загрузки профиля через SSH. You can configure the SSH server to use PowerShell as the default shell and to load a profile through SSH. Дополнительные сведения см. в документации по SSH. See the SSH documentation for more information.

До PowerShell 7.1 удаленное взаимодействие по SSH не поддерживало удаленные сеансы со вторым прыжком. Prior to PowerShell 7.1, remoting over SSH did not support second-hop remote sessions. Эта возможность была ограничена сеансами через WinRM. This capability was limited to sessions using WinRM. PowerShell 7.1 позволяет Enter-PSSession и Enter-PSHostProcess работать в любом интерактивном удаленном сеансе. PowerShell 7.1 allows Enter-PSSession and Enter-PSHostProcess to work from within any interactive remote session.