Windows 10 has a very useful implementation of OpenSSH to build up secure tunnels to remote systems. Compared to a tool like Putty, using the “ssh” command has some advantages, for example:
- Work with built-in tools (no need for Putty or others)
- Remote commands can be executed, i.e. you can open several tunnels after another for which otherwise you might need to open several instances of your remote connection program (like Putty)
- With the right configuration, you just need to type “ssh *myserver*” and OpenSSH does the rest – minimum interaction needed
- Dynamic port forwarding allows local applications to access otherwise inaccessible remote content without the need for reconfiguration (as long as you make sure they can handle SOCKS)
One thing that still requires interaction is when ssh asks you to enter the password for your private key. Even if you built up a neat SSH config as I will explain later, the ssh client will still ask you for a password for every single connection if your private key is password protected (what it hopefully is):
PS C:\Users\YourUser> ssh MyServer
Enter passphrase for key 'C:\Users\YourUser/.ssh/id_rsa':I will show you how you can store your private key in the OpenSSH Authentication Agent, so that you will not need to enter the password each time you build up an SSH tunnel. We will also briefly talk about agent forwarding, so that even on remote machines no password will be needed. But first let’s talk about the general SSH configuration. But first let’s see what is possible with the current implementation of OpenSSH in Windows 10 – and what not.
Setting up your SSH config
The example above assumes that you created the folder C:\Users\*YourUser*\.ssh and a file “config” that contains something like the following code:
Host MyServer
HostName IP.Of.Your.Server
User YourUserName
Port 22If you want, you can use port forwarding so that you can work from your local workstation with the remote system:
Host MyServer
HostName IP.Of.Your.Server
User YourUserName
Port 22
LocalForward 9999 localhost:9999This means, that if you browse to http://localhost:9999 on your local system, you can see data that the remote webserver is theoretically only providing locally for its own localhost. Of course, local and remote port which are both 9999 in the current example can be different. You can also forward multiple ports. If you have a proxy server running your remote host, you could forward that port and set up proxy-aware applications (for example your web browser) to use that proxy on that port.
ProxyJump – Currently not working
As mentioned in the list of advantages above, you can even execute a remote command after you established the tunnel, for example to built up another tunnel from the remote system to yet another system. OpenSSH therefore distinguishes between to methods: ProxyJump and ProxyCommand. If you simply want to jump from the first remote host to another remote host – which is most likely the case if your final system is only reachable via an intermediate bastion host – you could use ProxyJump. Unfortunately, as of now due to a bug in the Windows implementation of OpenSSH, this does not work. It apparently will be fixed in July 2020:
Host MyServer
HostName IP.Of.Your.Server
User YourTargetSystemUser
Port 22
LocalForward 9999 localhost:9999
ProxyJump YourProxyUser@IP.Of.Your.Proxy:22 # This does not work right now on Windows, but will probably be fixed in July 2020As soon as it will work you should be able to get it working even without a config file, by using the parameter “-J” instead:
ssh -J YourProxyUser@IP.Of.Your.Proxy:22 YourTargetSystemUser@IP.Of.Your.Server # This should work with newer versions of OpenSSH in Windows after July 2020This should log you in with “YourProxyUser” on IP.Of.Your.Proxy and from there you will be logged in to IP.Of.Your.Server with “YourTargetSystemUser”. Obviously, IP.Of.Your.Server needs to be reachable from the proxy/bastion. If DNS is working, you can of course also use a hostname instead of an IP address.
ProxyCommand – The flexible alternative
While ProxyJump is not working and as a more flexible alternative, you can also execute any command of your choice on the proxy using “ProxyCommand”. If you are working without a config file, you can use the parameter “-O” for ProxyCommand:
ssh -o ProxyCommand="ssh.exe -W %h:%p YourProxyUser@IP.Of.Your.Proxy:22" YourTargetSystemUser@IP.Of.Your.ServerNote that you cannot use ProxyCommand and ProxyJump in the same host configuration. For ProxyCommand, you can use some wildcards, as the manpage explains:
‘%h’ will be substituted by the host name to connect, ‘%p’ by the port, and ‘%r’ by the remote user name. The command can be basically anything, and should read from its standard input and write to its standard output. It should eventually connect an sshd server running on some machine, or execute sshd -i somewhere.
Actually, ProxyJump seems to be just a “shortcut” to use ProxyCommand: If you do use ProxyJump and set ssh to verbose output, you can see how it translates ProxyJump to ProxyCommand:
PS C:\Users\YourUser> ssh MyServer -v
[...]
debug1: Setting implicit ProxyCommand from ProxyJump: ssh -l YourProxyUser -p 22 -v -W '[%h]:%p' IP.Of.Your.Proxy
debug1: Executing proxy command: exec ssh -l YourProxyUser -p 22 -v -W '[IP.Of.Your.Server]:22' IP.Of.Your.ProxyHere you can also see the reason why it is not working – it is translated to “ssh”, but in current implementations of OpenSSH in Windows you need to indicate the full extension, i.e. “ProxyCommand ssh.exe”. This is still better than having to indicate the full path as it was required before due to another bug. So, let’s hope this will be fixed soon – or if it bugs you (haha), you can fix it manually.
Of course, you can also execute any other command apart from ssh, for example netcat, but also something like corkscrew to tunnel SSH through http proxies. If you want to learn more about the many things you can do with it, there are excellent tutorials on what is possible with ProxyCommand.
The important parameter for ProxyCommand is “-W”, which the manpage (for Linux) explains as follows:
-W host:port
Requests that standard input and output on the client be forwarded to host on port over the secure channel. Implies -N, -T, ExitOnForwardFailure and ClearAllForwardings and works with Protocol version 2 only.
We will have another look on how this works in the next section.
Chained Configurations
You can “cross-reference” within your SSH config. So let’s assume you have something like the following setup:
Host MyServer
HostName IP.Of.Your.Server
User YourTargetSystemUser
Port 22
ProxyCommand ssh.exe -W %h:%p Bastion # on Windows we need to add the ".exe"
Host Bastion
HostName IP.Of.Your.Proxy
User YourProxyUser
Port 22 # could of course also be any other portNow type:
ssh MyServerWhat will happen is that your local ssh client will take the “MyServer” configuration and see the line “ProxyCommand”. This tells the client that prior to executing the connection described in “MyServer”, it first will have to execute a command on an intermediary.
In the example above we are telling ssh that when it establishes a connection to IP.Of.Your.Server, it shall first run SSH on our local Windows 10 system, using the connection information provided in “Bastion”.
What I would like to note is that you can chain multiple times, but in practice I realized that things can easily break then. For work I’m using a fourfold jump, i.e. from my workstations over server 1, server 2, server 3 to server 4. This does work, but when I then try to use a service on server 3 – where port forwarding should allow me to do it – sometimes the connection cannot be established. An easy workaround is to build up a second connection that only jumps up to server 3 and ends there.
You can get a better understanding on how chaining works when you run ssh in verbose mode, i.e.:
ssh -v MyServerYou will then see the line:
debug1: Executing proxy command: exec ssh.exe -W IP.Of.Your.Server:22 BastionThis means, on that local Windows 10, it shall take the connection information from “Bastion” (%h = host “IP.Of.Your.Server”, %p = port “22”). Afterwards, it will forward the “MyServer” configuration over the standard input/output on the bastion host.
Default Settings
One last remark on the SSH config file: If you call your host “*”, all settings written there will be used as default, but can be overwritten in the specific host definitions. You can write the host definitions before or after the “*” host and in any order.
Host *
ForwardAgent noThere are other websites that explain all options that you can in the config file.
SSH Agent: Storing your key’s password
Normally, if you open a new ssh session, you will have to enter your private key’s password every single time. There are however ways how to prevent this. Obviously, you will need to decide by yourself if the gain in convenience is worth it to store your decrypted private key temporarily on your system, which theoretically can be accessed by malware.
Usually, other programs should not be able to access memory space of your ssh instance where you enter your password and where your private key is then decrypted. However, as soon as this instance ends (for example because you end the remote session), memory is freed up and your temporarily stored password-unprotected private key is gone. To make things a bit more persistent, a so-called ssh agent can run as a service and keep your password so that instances of ssh can ask the service for the required password. If you know Putty, you might already have worked with its ssh agent called “Pageant“. Obviously, it is not guaranteed that malicious software does not use the ssh agent’s services, hence you should have some trust in your system’s security posture. You should also not use this technique if somebody else with admin rights is working on your system, because they can read your key then.
The advantage of working with an ssh-agent is that you only will have to enter your private key’s password once and the service will keep it.
If you do want to use this convenient service, first you need to make sure that the authentication service is actually running: Press Win-R, type services.msc and look for “Open SSH Authentication Agent”. Make sure that the Startup type is on “Automatic”, and also don’t forget to start the service with “Start” if it was not running before. Then press OK to save the changes and close the window:
If you saved your private key with default path and name under *YourUserDirectory*\.ssh\rsa_id, you will not even have to provide any key name and just type:
ssh-addIf your key is named differently, type:
ssh-add /path/to/your/key/and_its_nameNow, you can simply add your private key, enter your password once and it will be stored for the duration of your Windows session. If for security reasons you only want to keep the key in the agent for a certain time, you can indicate the lifetime with the -t parameter, e.g. one hour would be:
ssh-add -t 1hTo verify which keys are currently stored in your agent, type:
ssh-add -LThis will return all keys that are currently held in memory for you by the agent. Oh, and if you created your key pair with Puttygen and therefore have to convert them to the OpenSSH format, just check out StackExchange.
Also here a quick note: For some reason, sessions sometimes seem to struggle to access the key from the agent and you will still have to enter your key manually again. Still figuring out what is the reason behind this…
Agent Forwarding: No password prompt anymore
The ssh agent ensures that for any further connection from your system to a remote system you will not need to enter your private key’s password anymore for the duration of the session. However, if you connect from your first remote system to another remote system and that system is asking for your private key as well, you will have to enter the password once more. Of course, you could store your private key on the first remote system and use an ssh agent there as well, but you should never copy your private key to any other system than your own. Moreover, your password for the private key would be readable on the remote machine if you typed it in there (it’s going through the SSH tunnel to the remote machine with encryption, but then goes out there to the standard output in unencrypted form).
SSH also has a solution for this: Agent forwarding allows remote systems to simply forward their key challenge to your local system – this even works across multiple hops and neither your private key, nor your password is ever transmitted. Nevertheless, only use agent forwarding with remote system you trust. Especially in enterprise environments, this option will often be disabled.
Note: I did not have a chance so far to try this out on Windows 10, so below is a description how it should work if OpenSSH is properly implemented.
To use agent forwarding, you have two possibilities: You can extend your SSH config (see above) with the following line:
ForwardAgent yesSome implementations of OpenSSH also allow to indicate forwarding as parameter, so when opening a connection – without the need for any config – you would simply type:
ssh -AFor some reason, the CLI parameter -A does not seem to be implemented for the Windows agent, though. You should also make sure that agent forwarding is actually supported and allowed by your target system. In the server config it needs to have this line:
AllowAgentForwarding yesFurther Reading
If you are not yet aware of them anyway, I recommend you to learn about the very useful possibilities that dynamic port forwarding brings.
I also recommend this site for an excellent overview on how key challenges – with and without agent forwarding work and another site for top 5 security recommendations.
PAM solutions might grant access to servers only temporarily and on-demand, which is an interesting concept that avoids to have orphaned keys lying around in the trusted keys folder.
В современных версиях Windows уже есть встроенный SSH сервер на базе пакета OpenSSH. В этой статье мы покажем, как установить и настроить OpenSSH сервер в Windows 10/11 и Windows Server 2022/2019 и подключиться к нему удаленно по защищенному SSH протоколу (как к Linux).
Содержание:
- Установка сервера OpenSSH в Windows
- Настройка SSH сервера в Windows
- Sshd_config: Конфигурационный файл сервера OpenSSH
- Подключение по SSH к Windows компьютеру
- Логи SSH подключений в Windows
Установка сервера OpenSSH в Windows
Пакет OpenSSH Server включен в современные версии Windows 10 (начиная с 1803), Windows 11 и Windows Server 2022/2019 в виде Feature on Demand (FoD). Для установки сервера OpenSSH достаточно выполнить PowerShell команду:
Get-WindowsCapability -Online | Where-Object Name -like ‘OpenSSH.Server*’ | Add-WindowsCapability –Online
Или при помощи команды DISM:
dism /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0
Если ваш компьютер подключен к интернету, пакет OpenSSH.Server будет скачан и установлен в Windows.
Также вы можете установить сервер OpenSSH в Windows через современную панель Параметры (Settings -> Apps and features -> Optional features -> Add a feature, Приложения -> Управление дополнительными компонентами -> Добавить компонент. Найдите в списке OpenSSH Server и нажмите кнопку Install).
На изолированных от интернета компьютерах вы можете установить компонент с ISO образа Features On Demand (доступен в личном кабинете на сайте Microsoft: MSDN или my.visualstudio.com). Скачайте диск, извлеките его содержимое в папку c:\FOD (достаточно распаковать извлечь файл
OpenSSH-Server-Package~31bf3856ad364e35~amd64~~.cab
), выполните установку из локального репозитория:
Add-WindowsCapability -Name OpenSSH.Server~~~~0.0.1.0 -Online -Source c:\FOD
Также доступен MSI установщик OpenSSH для Windows в официальном репозитории Microsoft на GitHub (https://github.com/PowerShell/Win32-OpenSSH/releases/). Например, для Windows 10 x64 нужно скачать и установить пакет OpenSSH-Win64-v8.9.1.0.msi. Следующая PowerShell команда скачает MSI файл и установит клиент и сервер OpenSSH:
Invoke-WebRequest https://github.com/PowerShell/Win32-OpenSSH/releases/download/v8.9.1.0p1-Beta/OpenSSH-Win64-v8.9.1.0.msi -OutFile $HOME\Downloads\OpenSSH-Win64-v8.9.1.0.msi -UseBasicParsing
msiexec /i c:\users\root\downloads\OpenSSH-Win64-v8.9.1.0.msi
Также вы можете вручную установить OpenSSH сервер в предыдущих версиях Windows (Windows 8.1, Windows Server 2016/2012R2). Пример установки Win32-OpenSSH есть в статье “Настройка SFTP сервера (SSH FTP) в Windows”.
Чтобы проверить, что OpenSSH сервер установлен, выполните:
Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Ser*'
State : Installed
Настройка SSH сервера в Windows
После установки сервера OpenSSH в Windows добавляются две службы:
- ssh-agent (OpenSSH Authentication Agent) – можно использовать для управления закрытыми ключами если вы настроили SSH аутентификацию по ключам;
- sshd (OpenSSH SSH Server) – собственно сам SSH сервер.
Вам нужно изменить тип запуска службы sshd на автоматический и запустить службу с помощью PowerShell:
Set-Service -Name sshd -StartupType 'Automatic'
Start-Service sshd
С помощью nestat убедитесь, что теперь в системе запущен SSH сервер и ждет подключений на порту TCP:22 :
netstat -na| find ":22"
Проверьте, что включено правило брандмауэра (Windows Defender Firewall), разрешающее входящие подключения к Windows по порту TCP/22.
Get-NetFirewallRule -Name *OpenSSH-Server* |select Name, DisplayName, Description, Enabled
Name DisplayName Description Enabled ---- ----------- ----------- ------- OpenSSH-Server-In-TCP OpenSSH SSH Server (sshd) Inbound rule for OpenSSH SSH Server (sshd) True
Если правило отключено (состоянии Enabled=False) или отсутствует, вы можете создать новое входящее правило командой New-NetFirewallRule:
New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22
Рассмотрим, где храниться основные компоненты OpenSSH:
- Исполняемые файлы OpenSSH Server находятся в каталоге
C:\Windows\System32\OpenSSH\
(sshd.exe, ssh.exe, ssh-keygen.exe, sftp.exe и т.д.) - Конфигурационный файл sshd_config (создается после первого запуска службы):
C:\ProgramData\ssh - Файлы authorized_keys и ssh ключи можно хранить в профиле пользователей:
%USERPROFILE%\.ssh\
Sshd_config: Конфигурационный файл сервера OpenSSH
Настройки сервере OpenSSH хранятся в конфигурационном файле %programdata%\ssh\sshd_config. Это обычный текстовый файл с набором директив. Для редактирования можно использовать любой текстовый редактор (я предпочитаю notepad++). Можно открыть с помощью обычного блокнота:
start-process notepad C:\Programdata\ssh\sshd_config
Например, чтобы запретить SSH подключение для определенного доменного пользователя (и всех пользователей указанного домена), добавьте в конце файле директивы:
DenyUsers winitpro\[email protected] DenyUsers corp\*
Чтобы разрешить подключение только для определенной доменной группы:
AllowGroups winitpro\sshadmins
Либо можете разрешить доступ для локальной группы:
AllowGroups sshadmins
По умолчанию могут к openssh могут подключаться все пользователи Windows. Директивы обрабатываются в следующем порядке: DenyUsers, AllowUsers, DenyGroups,AllowGroups.
Можно запретить вход под учетными записями с правами администратора, в этом случае для выполнения привилегированных действий в SSH сессии нужно делать runas.
DenyGroups Administrators
Следующие директивы разрешают SSH доступ по ключам (SSH аутентификации в Windows с помощью ключей описана в отдельной статье) и по паролю:
PubkeyAuthentication yes PasswordAuthentication yes
Вы можете изменить стандартный SSH порт TCP/22, на котором принимает подключения OpenSSH в конфигурационном файле sshd_config в директиве Port.
После любых изменений в конфигурационном файле sshd_config нужно перезапускать службу sshd:
restart-service sshd
Подключение по SSH к Windows компьютеру
Теперь вы можете попробовать подключиться к своей Windows 10 через SSH клиент (в этом примере я использую putty).
Вы можете использовать встроенный SSH клиентом Windows для подключения к удаленному хосту. Для этого нужно в командной строке выполнить команду:
ssh [email protected]
В этом примере
alexbel
– имя пользователя на удаленном Windows компьютере, и 192.168.31.102 – IP адрес или DNS имя компьютера.
Обратите внимание что можно использовать следующие форматы имен пользователей Windows при подключении через SSH:
-
alex@server1
– локальный пользователь Windows -
[email protected]@server1
–пользователь Active Directory (в виде UPN) или аккаунт Microsoft/ Azure(Microsoft 365) -
winitpro\alex@server1
– NetBIOS формат имени
В домене Active Directory можно использовать Kerberos аутентификацию в SSH. Для этого в sshd_config нужно включить параметр:
GSSAPIAuthentication yes
После этого можно прозрачно подключать к SSH сервер с Windows компьютера в домене из сессии доменного подключается. В этом случае пароль пользователя не указывается и выполняется SSO аутентификация через Kerberos:
ssh -K server1
При первом подключении появится стандартный запрос на добавление узла в список известных SSH хостов.
Нажимаем Да, и в открывшееся окне авторизуемся под пользователем Windows.
При успешном подключении запускается командная оболочка cmd.exe со строкой-приглашением.
admin@win10tst C:\Users\admin>
В командной строке вы можете выполнять различные команды, запускать скрипты и программы.
Я предпочитаю работать в командной строке PowerShell. Чтобы запустить интерпретатор PowerShell, выполните:
powershell.exe
Чтобы изменить командную оболочку (Shell) по умолчанию в OpenSSH с cmd.exe на PowerShell, внесите изменение в реестр такой командой:
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String –Force
Осталось перезапустить SSH подключение и убедиться, что при подключении используется командный интерпретатор PowerShell (об этом свидетельствует приглашение
PS C:\Users\admin>
).
В SSH сессии запустилась командная строка PowerShell, в которой работают привычные функции: авто дополнение, раскраска модулем PSReadLine, история команд и т.д. Если текущий пользователь входит в группу локальных администраторов, то все команды в его сессии выполняются с повышенными правами даже при включенном UAC.
Логи SSH подключений в Windows
В Windows логи подключений к SSH серверу по-умолчанию пишутся не в текстовые файлы, а в отдельный журнал событий через Event Tracing for Windows (ETW). Откройте консоль Event Viewer (
eventvwr.msc
>) и перейдите в раздел Application and services logs -> OpenSSH -> Operational.
При успешном подключении с помощью к SSH серверу с помощью пароля в журнале появится событие:
EventID: 4 sshd: Accepted password for root from 192.168.31.53 port 65479 ssh2
Если была выполнена аутентификация с помощью SSH ключа, событие будет выглядеть так:
sshd: Accepted publickey for locadm from 192.168.31.53 port 55772 ssh2: ED25519 SHA256:FEHDEC/J72Fb2zC2oJNb45678967kghH43h3bBl31ldPs
Если вы хотите, чтобы логи писались в локальный текстовый файл, нужно в файле sshd_config включить параметры:
SyslogFacility LOCAL0 LogLevel INFO
Перезапустите службу sshd и провеьте, что теперь логи SSH сервера пишутся в файл C:\ProgramData\ssh\logs\sshd.log
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!
В последних билдах Windows 10 появился встроенный SSH сервер и клиент на базе OpenSSH. Это значит, что теперь вы можете удаленно подключаться к компьютеру Windows 10/11 (Windows Server 2019/2022) с помощью любого SSH клиента, как к Linux. В этой статье мы покажем, как настроить OpenSSH в Windows 10 и подключится к нему с помощью putty или любого другого SSH клиента.
Убедитесь, что ваша версия Windows 10 1809 или выше. Проще всего это сделать, выполнив команду:
winver
Совет. Если у вас более старая версия Windows 10 вы можете обновить ее через Windows Update или с помощью ISO образа с более новой версией Windows 10 (можно создать его с помощью Media Creation Tool). Если вы не хотите обновлять Windows 10, вы можете вручную установить порт OpenSSH для Windows с GitHub — Win32-OpenSSH (https://github.com/PowerShell/Win32-OpenSSH).
Вы можете включить OpenSSH сервера в Windows 10 через панель Параметры:
- Перейдите в Settings -> Apps -> Optional features;
- Нажмите Add a feature, выберите OpenSSH Server и нажмите Install;
Также вы можете установить sshd сервер в Windows с помощью PowerShell:
Add-WindowsCapability -Online -Name OpenSSH.Server*
Или с помощью DISM:
dism /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0
Если вы хотите убедитесь, что OpenSSH сервер установлен, выполните следующую команду:
Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Server*'
Name : OpenSSH.Server~~~~0.0.1.0 State : Installed
Проверьте статус служб ssh-agent и sshd с помощью командлета Get-Service:
Get-Service -Name *ssh*
Как вы видите, обе службы находятся в состоянии Stopped и не добавлены в автозагрузку. Чтобы запустить службы и настроить для них автозапуск, выполните команды:
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
Start-Service ‘ssh-agent’
Set-Service -Name ‘ssh-agent’ -StartupType 'Automatic'
Также нужно разрешить входящие подключения на порт TCP 22 в Windows Defender Firewall:
netsh advfirewall firewall add rule name="SSHD service" dir=in action=allow protocol=TCP localport=22
Теперь вы можете подключиться к Windows 10 с помощью любого SSH клиента. Для подключения из Linux используете команду:
ssh -p 22 admin@192.168.1.90
где, admin – имя локального пользователя Windows, под которым вы хотите подключиться
192.168.1.90 – ip адрес вашего компьютера с Windows 10
После этого откроется окно командной строки Windows.
Совет. Чтобы вместо оболочки cmd.exe при подключении к Windows 10 через SSH запускалась консоль PoweShell, нужно выполнить команду:
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String –Force
Так вы измените оболочку, которая стартует через OpenSSH. Теперь при подключении к Windows по SSH у вас будет сразу открываться консоль PowerShell вместо командной строки cmd.exe.
Если вы хотите использовать key-based ssh authentification вместо парольной аутентификации, нужно на вашем клиенте сгенерировать ключ с помощью ssh-keygen.exe.
Затем содержимое файла id_rsa.pub нужно скопировать в файл c:\users\admin\.ssh\authorized_keys в Windows 10.
После этого вы сможете подключаться с вашего Linux клиента к Windows 10 без пароля. Используйте команду:
ssh -l admin@192.168.1.90
Вы можете настроить различные параметры OpenSSH сервера в Windows с помощью конфигурационного файла %programdata%\ssh\sshd_config
Например, вы можете отключить аутентификацию по паролю и разрешить вход только по ключу:
PubkeyAuthentication yes PasswordAuthentication no