Prerequisites
- Windows Subsystem for Linux (WSL) is installed
- For this example we will use the Ubuntu Linux distro/distribution.
- Visit this link to rocket academy to find out more about WSL
Step 1: Understand how to access Linux On Windows
Method 1: Using the file explorer
-
Type
\\wsl$\
into the file explorer. This will direct you to the location of the Ubuntu folder. -
Navigate to your linux folder.
Ubuntu -> Home -> <LINUX USERNAME>
Method 2: Using the WSL terminal
# This command navigates to the linux folder
cd ~/
Enter fullscreen mode
Exit fullscreen mode
# This command lists the files that are in the linux folder
ls -a ~
Enter fullscreen mode
Exit fullscreen mode
Step 2: Create .ssh folder (this is where we’ll put the ssh key)
Notes: If this is your first time accessing this folder, you probably do not have a folder for ssh files and will have to create your own.
Method 1: Using the file explorer
- Create a folder in your linux folder and name it «.ssh»
- Done! Now you can put the key pairs in this folder
Method 2: Using the WSL terminal
# 1. Check if you have a .ssh folder. If you don't have an ssh folder it'll return "No such file or directory"
ls ~/.ssh
Enter fullscreen mode
Exit fullscreen mode
# 2. Create a folder called .ssh
mkdir ~/.ssh
Enter fullscreen mode
Exit fullscreen mode
# 3. Copy any key pairs you need into this folder
# Note: You have to be in the same directory as the file you want to copy
# syntax: cp <FILENAME> ~/.ssh
cp my-aws-ec2-keypair.pem ~/.ssh
Enter fullscreen mode
Exit fullscreen mode
В этой статье мы настроим 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 [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 туннеле, запуска скриптов и других задачах автоматизации.
In Windows 10, finding your SSH public key is a necessary skill, especially if you want to connect securely to remote servers or share your public key for access to certain services. To locate your SSH public key, you’ll need to navigate to where it’s stored on your computer. The process involves using Windows’ built-in terminal to search your system for the key file.
In this section, I’ll guide you through finding your SSH public key on a Windows 10 machine. By following these simple steps, you’ll be able to easily locate and view your key.
Step 1: Open Command Prompt or PowerShell
To get started, open the Command Prompt or PowerShell on your Windows 10 computer.
You can do this by typing “cmd” or “PowerShell” in the Start menu search bar and hitting Enter. Both Command Prompt and PowerShell will work for this task, but PowerShell tends to offer more features.
Step 2: Navigate to the .ssh Directory
Next, navigate to the .ssh directory by typing cd %userprofile%.ssh
and pressing Enter.
This command jumps straight to the .ssh folder within your user profile, where your SSH keys are usually stored. If you receive an error, the .ssh directory might not exist yet, indicating you need to generate a key.
Step 3: List the Files
Once you’re in the .ssh directory, list all files by typing dir
in Command Prompt or ls
in PowerShell.
You should see a list of files, one of which will likely be named id_rsa.pub
or id_ecdsa.pub
. These are common names for SSH public key files. If no such file exists, you might need to generate a new SSH key pair.
Step 4: Display the Public Key
To view your public key, type type id_rsa.pub
in Command Prompt or cat id_rsa.pub
in PowerShell.
This command displays the contents of the id_rsa.pub
file, which is your public key. The text that appears is what you would share with others to allow them to verify your identity securely.
Step 5: Copy the Key
Finally, copy the displayed key by selecting the text and using Ctrl + C.
Ensure you select the entire key, as partial keys won’t work. You can then paste it wherever you need, such as on a GitHub account or remote server configuration.
After you complete these steps, you should be able to access your SSH public key. This key can be shared safely with others or used to configure your access to servers and services. Remember, never share your private key, as doing so can compromise your security.
Tips for Finding Your SSH Public Key in Windows 10
- Ensure your SSH key exists by checking for
id_rsa.pub
orid_ecdsa.pub
in the .ssh directory. - If the key isn’t found, generate one using
ssh-keygen
in your terminal. - Use PowerShell for more advanced features and better command support.
- Keep a backup of your SSH keys in a secure location for easy retrieval.
- Always be cautious and never share your private SSH key.
Frequently Asked Questions
What if I can’t find the .ssh folder?
If the .ssh folder doesn’t exist, you may need to generate a key pair. Use ssh-keygen
in PowerShell to create it.
How do I generate a new SSH key?
Run ssh-keygen
in PowerShell and follow the prompts to create a new key pair.
Can I have multiple SSH keys?
Yes, you can generate multiple keys for different purposes. Name them uniquely to keep track.
How do I secure my SSH keys?
Store them in a safe location and restrict file permissions. Never share your private key.
What is the difference between a private and public key?
The public key is shared to verify your identity, while the private key is kept secret to secure your access.
Summary
- Open Command Prompt or PowerShell.
- Navigate to the .ssh directory.
- List the files.
- Display the public key.
- Copy the key.
Conclusion
Understanding how to find your SSH public key in Windows 10 is an essential skill for anyone dealing with secure server connections or software development. By mastering these steps, you ensure that you’re equipped to manage your secure connections efficiently. This knowledge not only enhances your technical abilities but also bolsters your confidence when interacting with digital security measures.
Once you’ve located your SSH public key, you’ll likely find yourself using it in various contexts, whether it’s accessing remote servers, collaborating on GitHub, or any other application that requires secure access. Remember always to keep your private key safeguarded to prevent unauthorized access. In today’s digital age, managing your SSH keys is akin to having the keys to your digital kingdom—treat them with care.
For those interested in learning more, further reading on SSH key management, security practices, and additional configuration options can be invaluable. Dive deeper into topics like key generation methods, advanced configuration, or integrating SSH keys with various platforms. The more you understand about these tools, the more control you’ll have over your digital security landscape.
Matt Jacobs has been working as an IT consultant for small businesses since receiving his Master’s degree in 2003. While he still does some consulting work, his primary focus now is on creating technology support content for SupportYourTech.com.
His work can be found on many websites and focuses on topics such as Microsoft Office, Apple devices, Android devices, Photoshop, and more.
SSH • Windows • Конфигурирование • OpenSSH • Компьютерные истории • Истории
Введение
Начиная с верcии 1803
, в Windows 10
доступны SSH
клиент и SSH
сервер, причём, SSH
клиент установлен и готов к использованию, как говорится, прямо из коробки, а SSH
сервер надо устанавливать, но делается это буквально в пару-тройку кликов мышкой[1]. Что это означает? С точки зрения клиента можно говорить о том, что сторонние программы, такие как PuTTY
, вроде как больше не нужны. С точки зрения сервера — не надо устанавливать никакие сторонние серверы, если есть решение интегрированное.
В работе что клиент, что сервер, практически не отличаются от того ПО, к которому я привык в Debian
. Но, как ни крути, есть некоторые отличия, и вот об одном из них попробую сейчас рассказать. Речь пойдет о подключении к SSH
серверу, работающему на Windows
, с клиента, в моем случае, работающего на Debian Jessie
, причем, без использования пароля, то есть, задействуя ключи.
На самом деле, начало процесса не отличается от стандартного: если у вас нет набора ключей, вам его надо сгенерировать, если есть — используйте существующий. Речь сейчас идёт о той машине, которая будет клиентом. И я уже как-то писал об этом, но на некоторых моментах всё-таки остановлюсь ещё раз: повторенье — мать ученья 😉.
Про генерацию ключей
Итак, если ключей нет и вы работаете на системе под управлением Linux
, то вот эта команда поможет вам их сгенерировать:
ssh-keygen -t rsa
Если же вы работаете под Windows
, то у вас есть несколько возможностей сгенерировать ключи:
- Если вы работаете под
Windows 10
и включили возможность использовать встроенныйSSH
клиент, то смело используйте командуssh-keygen
— должно сработать… 🙄😉 - Если вы работаете под
Windows 10
и включили возможность использовать WSL, то можете воспользоваться возможностями этой подсистемы, то есть, использовать в ней… всё ту же командуssh-keygen
. - Если вы работаете под
Windows 10
и у вас не установлен встроенныйSSH
клиент и не включена возможность использованияWSL
, или же у вас более ранняя версияWindows
, то придется использовать стороннее ПО, тот же PuTTY с его генераторомPuTTYgen
— для этого случая есть достаточно подробная документация.
Если пара ключей успешно сгенерирована, или уже была у вас, то необходимо «доставить» публичный ключ на сервер и там сделать его доступным для использования SSH
сервером. И вот тут то и начинаются отличия от обычного — для мира Linux
— процесса.
Доставка публичного ключа на сервер Linux
Что я делал, когда мне надо было «доставить» ключ на SSH
сервер, работающий на Linux
? Всё очень просто — запуск следующей команды на клиентской машине решал все вопросы:
ssh-copy-id user_name@server_name_or_ip
где user_name — имя пользователя, ключ которого передаётся на сервер, а server_name_or_ip — имя или адрес хоста с сервером SSH
, к которому есть желание подключаться без ввода пароля (от имени пользователя с ключом). Иногда команда не работала и приходилось явно указывать файл (при помощи параметра командной строки -i
), в котором хранился публичный ключ, но это, в большей степени, зависело от устройства, на котором выполнялась эта команда, вернее, от версии ОС, ну и от реализации и версии криптографического ПО, конечно.
Но, в случае, когда в качестве сервера выступает машина с Windows
, этот приём не прокатывает — ключ не передаётся на нужный хост и всё. Не знаю, эксперименты эти я проводил довольно давно, может, в новых версиях Windows
эту «особенность» исправили, а может и нет. В любом случае, тогда мне пришлось искать обходной путь.
Собственно, сам этот путь очевиден — раз не получается сделать передачу ключа автоматом, надо всё выполнить вручную. А для этого необходимо знать, где и как Windows
хранит публичные ключи, используемые SSH
сервером для аутентификации клиентов. К счастью, в документации Microsoft
есть необходимая информация и её надо просто использовать. Давайте её детально разберём, при том держа в уме, что документация предполагает работу с клиентской машины под управлением Windows
с заранее настроенным доступом по SSH
к необходимому серверу.
Создание каталога для хранения ключей
Итак, из документации становится очевидно, что Windows
хранит пользовательские ключи, используя тот же принцип, что и Linux
: на сервере в файле authorized_keys
в подкаталоге .ssh
домашнего каталога пользователя (а это, как правило, c:\Users\user_name
, где user_name — имя пользователя), от имени которого вы хотите работать в установившемся SSH
сеансе. Если этого каталога нет, его надо создать, для чего предлагается использовать команду:
ssh user_name@domain_name@host_name "mkdir C:\\users\\user_name\\.ssh\\"
где user_name — имя пользователя, domain_name — имя домена, в который входит пользователь (его можно опустить для локальных пользователей на удалённом сервере), host_name — имя или адрес хоста, к которому подключаемся. Приведённая мною команда несколько отличается от той, которая дана в документации, но следует помнить, что я работаю с клиентской машины под управлением Linux
.
Копирование публичного ключа
Далее, предлагается скопировать во вновь созданный каталог файл с публичным ключом пользователя, от имени которого вы работаете на клиентской машине при подключении к серверу по SSH
(команда слегка отличается от той, которая приведена в документации, так как я работаю с машины под управлением Debian
):
scp ~/.ssh/public_key_file_name.pub user_name@domain_name@host_name:C:\Users\user_name\.ssh\authorized_keys
где public_key_file_name.pub — имя файла публичного ключа, например, id_ed25519.pub
или id_rsa.pub
(далее в примерах я буду использовать для простоты id_rsa.pub
).
На этом моменте хотелось бы остановиться подробнее. Обычно вы работаете на своём компьютере (или виртуалке) под своим собственным пользователем. Когда вы подключаетесь к удалённой машине по SSH
, вы можете подключаться под именем своего текущего пользователя локальной машины, или использовать имя какого-либо пользователя удалённого компьютера, или же — доменное имя. Конечно, в любом случае на удалённом хосте должен существовать соответствующий пользователь (или разрешено использовать доменное имя), даже если его имя будет совпадать с именем пользователя, под которым вы работаете на своём локальном хосте. Так вот, совсем не обязательно, что вы единственный подключаетесь к удалённому хосту под определенным пользователем, вполне возможно, что с других хостов другие люди (или вы сами?) также подключаются по SSH
, используя ту же самую учётную запись.
Возможно то, что я написал выше, это «ужас-ужас» с точки зрения безопасности, но такая ситуация весьма вероятна в домашних и небольших офисных сетях (да и не только 🙁), в которых не сильно заморачиваются с администрированием. И вот в таких случаях, копировать файл со своим публичным ключом — плохая идея: вы просто затрёте существующий файл authorized_keys
с публичными ключами других пользователей (или ваших собственных ключей на других компьютерах — вряд ли вы переносите свою единственную пару ключей с хоста на хост 😉). Поэтому следует рассмотреть возможность добавлять свой ключ к соответствующему файлу на удалённом хосте.
Добавление публичного ключа
Естественно, возникает вопрос, как это можно сделать. И на этот вопрос существует множество ответов. Например, если у вас есть доступ к удалённому хосту по RDP
, то можно отредактировать на нём файл authorized_keys
с помощью того же notepad
-а, добавив содержимое своего файла с публичным ключом. Или же, можно скопировать свой файл с публичным ключом на нужный сервер и объединить его с существующим файлом, а затем — удалить (конечно, при этом у вас, вернее, у вашего пользователя на удалённом компьютере, должны быть права на редактирование файла authorized_keys
):
scp ~/.ssh/id_rsa.pub user_name@domain_name@host_name:C:/Users/user_name/.ssh/my_public_key_file_name.pub
ssh user_name@domain_name@host_name "type C:\\Users\\user_name\\.ssh\\my_public_key_file_name.pub >> C:\\Users\\user_name\\.ssh\\authorized_keys"
ssh user_name@domain_name@host_name "del /Q C:\\Users\\user_name\\.ssh\\my_public_key_file_name.pub"
Обратите внимание на использование символов ‘/’ в команде scp
и ‘\’ в командах ssh
— так как мы работаем на Debian
, то в команду scp
можно передать путь на хосте с Windows
с использованием нестандартного для Windows
разделителя ‘/’, а вот в команды, выполняемые при помощи ssh
на том же удалённом компьютере, следует передавать символы ‘\’,то есть, стандартный для Windows
разделитель ‘\’ с предшествующим символом ‘\’, так называемый «escaped backslash», иначе Windows
не найдёт нужные файлы.
Назначение прав доступа к файлу с публичными ключами
Вот мы и подошли к последнему шагу — предоставлению прав доступа к файлу authorized_keys
. Именно этим занимается команда:
ssh --% user_name@domain_name@host_name powershell -c $ConfirmPreference = 'None'; Repair-AuthorizedKeyPermission C:\Users\user_name\.ssh\authorized_keys
Основную смысловую нагрузку в этой составной команде несёт функция Repair-AuthorizedKeyPermission
из модуля OpenSSHUtils
для PowerShell
(да, именно PowerShell
используется в качестве командной оболочки в этот раз). Этот модуль надо устанавливать отдельно, например, так (выполнять эту команду надо, естественно, из PowerShell
):
Install-Module -Force OpenSSHUtils -Scope AllUsers
Так вот, когда я запустил эту команду, ответом мне стало сообщение об ошибке:
Совпадения для указанных условий поиска и имени пакета "OpenSSHUtils" не найдены.
Естествено, я начал разбираться в сложившейся ситуации, после чего, если честно, желание использовать этот модуль у меня стало исчезающе малым.
Суть в том, что Windows 10
предъявляет определённые требования к безопасности файла authorized_keys
(на самом деле, к безопасности публичных ключей). Причины, по которым это происходит, наверное, не надо объяснять. Так вот, в документации Microsoft
указывается, что при использовании Windows 10
доступ может быть предоставлен только администаторам и специальному пользователю SYSTEM
. Там же советуется использовать модуль OpenSSHUtils
, который должен оказать помощь при установке нужных прав. Собственно, при использовании предложенного в документации подхода я и наткнулся на ошибку. Но кроме документации от Microsoft
я нашёл довольно много информации о проблемах, вызванных использованием этого модуля. Если попробовать кратко изложить содержимое ответов на возникающие у пользователей вопросы и проблемы, то получится что-то типа:
«Не используйте этот модуль, он дополнительно предоставит права пользователю
sshd
, после чего у вас перестанут соблюдаться требования к безопасности публичных ключей.»
Вот честно, не знаю, так это, или нет, но проверять расхотелось, тем более, что совсем не трудно задать нужные права самостоятельно. После некоторого изучения вопроса — я не большой специалист в PowerShell
— получился вот такой вот набор команд[2] (я приведу их полностью, потом разберу для чего нужна каждая из них):
$acl = Get-Acl C:\Users\user_name\.ssh\authorized_keys
$acl.SetAccessRuleProtection($true, $false)
$adminsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Администраторы","FullControl","Allow")
$sysRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($adminsRule)
$acl.SetAccessRule($sysRule)
Set-Acl -Path C:\Users\user_name\.ssh\authorized_keys -AclObject $acl
Теперь, как и обещал, небольшие пояснения по командам. Итак, для начала, при помощи cmdlet
-а Get-Acl получаем дескриптор безопасности, содержащий ACL
(Access Control List) нужного нам объекта файловой системы (параметр командной строки Path
можно опустить) и сохраняем результат в переменной $acl
. Далее, используя метод SetAccessRuleProtection полученного объекта, запрещаем наследование прав (true
в первом параметре) и отказываемся от сохранения унаследованных ранее прав (false
во втором параметре). Затем создаём два объекта, описывающих правила доступа к объектам файловой системы: один (сохраняется в переменной $adminsRule
) — для Администраторов, второй (сохраняется в переменной $sysRule
) — для специального пользователя SYSTEM
. Теперь, при помощи метода SetAccessRule, добавляем только что соданные ACL
к дескриптору безопасности нашего файла, хранящегося в переменной $acl
. После чего, всё, что нам остаётся сделать — применить полученный дескриптор, для чего используем cmdlet
Set-Acl.
Ну вот, теперь, когда мы выполнили все шаги, всё должно заработать. Но, в моём случае, не заработало. Очередная неудача заставила меня вновь полезть в документацию, что обогатило меня новыми знаниями. Рассказываю…
Публичные ключи для работы от имени пользователей администраторов
Причиной того, что при соединении с SSH
сервером мне, несмотря на все предыдущие мытарства, продолжало выводиться требование ввести пароль, было то, что я пытался подключиться под пользователем, который входил в группу локальных Администраторов. У Windows 10
в этом случае есть требование — публичные ключи должны храниться в файле %programdata%/ssh/administrators_authorized_keys
, то есть, обычно, в C:\ProgramData\ssh\administrators_authorized_keys
.
Что ж, для того, чтобы решить проблему, можно воспользоваться двумя путями. Первый путь — воспользоваться процедурой добавления публичного ключа, рассмотренной нами выше. Да-да, все эти шаги: копирование, добавление, предоставление прав, только применяем их не к authorized_keys
, а к administrators_authorized_keys
. Я напишу, на всякий случай, полную последовательность команд, чтобы удобно было воспользоваться, но не забудьте подставить свои значения для пользователя, домена и хоста.
scp ~/.ssh/id_rsa.pub user_name@domain_name@host_name:C:/Users/user_name/.ssh/my_public_key_file_name.pub
ssh user_name@domain_name@host_name "type C:\\Users\\user_name\\.ssh\\my_public_key_file_name.pub >> C:\\ProgramData\\ssh\\administrators_authorized_keys"
ssh user_name@domain_name@host_name "del /Q C:\\Users\\user_name\\.ssh\\my_public_key_file_name.pub"
$acl = Get-Acl C:\ProgramData\ssh\administrators_authorized_keys
$acl.SetAccessRuleProtection($true, $false)
$adminsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Администраторы","FullControl","Allow")
$sysRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($adminsRule)
$acl.SetAccessRule($sysRule)
Set-Acl -Path C:\ProgramData\ssh\administrators_authorized_keys -AclObject $acl
Второй путь чуть более радикальный — изменить настройки SSH
сервиса. Настройки эти хранятся в файле %programdata%/ssh/sshd_config
. Как оказалось, именно там определяется, где должны храниться публичные ключи тех пользователей, которые подключаются к SSH
серверу от имени пользователей, входящих в группу администраторов. Вот, собственно, эти строки:
...
Match Group administrators
AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
...
Так вот, эти строки надо закомментировать или удалить, после чего SSH
сервер надо перезапустить.
Какой путь использовать — решать вам. Я же, пожалуй, закончу — пост получился и так слишком длинным…
-
На самом деле, в виде beta версий эти компоненты были доступны и раньше, но и установка и стабильность работы, были, что называется, не на высоте. ↩︎
-
Честно признаюсь, очень многое я подсмотрел в документации, например, как отключить наследование прав, или предоставить Администраторам полный контроль над файлом, и лишь немного адаптировал эти примеры к собственным нуждам. ↩︎
Subscribe to Записки на полях
Get the latest posts delivered right to your inbox
Great! Check your inbox and click the link to confirm your subscription.
Please enter a valid email address!
The realm of Windows, typically associated with GUI-driven operations, has seen significant shifts in its landscape, with a burgeoning embrace of Unix-like utilities and features. One such feature, which has found its way from the Unix world to Windows, is SSH (Secure Shell) and, with it, the notable
.ssh
folder.
What is the
.ssh
Folder?
Originally hailing from Unix-based systems, the
.ssh
directory is a hidden folder that plays a pivotal role in SSH key management. Within this folder, users store vital information, including:
Private and Public Key Pairs
: These are essential for asymmetric encryption, allowing users to securely authenticate to remote servers without the need for a password.
known_hosts
: A file that keeps a record of remote hosts to which the user has connected, helping in the prevention of man-in-the-middle attacks.
config
: An optional file that allows users to define specific SSH configurations for different hosts.
Where Can You Find the
.ssh
Folder in Windows?
The location of the
.ssh
folder varies based on the tool or environment you’re utilizing:
Windows Subsystem for Linux (WSL)
:
Within the WSL environment, the path remains true to its Unix roots. You’d find the
.ssh
directory at:
/home/your_username/.ssh/
.
Git Bash
:
A popular tool among developers, Git Bash simulates a Unix-like shell in Windows. Here, the
.ssh
folder adheres to the convention:
C:\Users\your_username\.ssh\
.
Native OpenSSH client in Windows 10
:
Microsoft integrated a native OpenSSH client starting with Windows 10 build 1803. In this setup, the directory resides in:
C:\Users\your_username\.ssh\
.
Cygwin
:
For those using the Cygwin environment to replicate a Unix-like feel on Windows, the path to the
.ssh
directory is:
C:\cygwin64\home\your_username\.ssh\
.
Setting Up SSH Keys in Windows:
Windows users, especially those diving into development or server management, often need to set up SSH keys for secure communication. Here’s a brief guide:
ssh-keygen
tool:
Follow the prompts. By default, this process will generate a private key (
id_rsa
) and a public key (
id_rsa.pub
) in the aforementioned
.ssh
directory.
Always remember: Your private key (
id_rsa
) is akin to a password. Safeguard it and never share it. The public key (
id_rsa.pub
), on the other hand, is shared with servers or services to which you want to authenticate.
Conclusion
The introduction and growing prominence of the
.ssh
directory in Windows is testament to the blending of two distinct tech worlds. As Windows continues to interlace with Unix-like features, understanding the intricacies of such elements becomes essential for modern users. The
.ssh
folder, while a small piece of this puzzle, is instrumental in ensuring secure and seamless communication in a connected digital era.