Встроенный OpenSSH в Windows с клиентом, сервером и практикой туннелей для администратора

Многие администраторы годами таскали на флешке набор сторонних утилит, чтобы получить нормальный терминальный доступ к серверам с машины на Windows, не подозревая, что нужный инструмент уже лежит внутри системы. Начиная с Windows 10 и Windows Server 2019, OpenSSH поставляется как официальный компонент: клиентская часть устанавливается по умолчанию, а серверная добавляется через список опциональных компонентов. Это значит, что полноценные ssh, scp, sftp и ssh-add доступны из любой консоли без единой установки стороннего ПО, а служба sshd превращает любую машину на Windows в управляемый узел с шифрованным каналом. Дальше разберём, как всё это поставить, настроить аутентификацию по ключам, обойти классические грабли с правами, строить туннели и подключить привычную среду разработки.

Установка клиента и сервера через необязательные компоненты

Клиент OpenSSH в свежих сборках Windows 10 и Windows 11 ставится сам, и команда ssh работает в PowerShell или командной строке сразу после установки системы. Проверить наличие проще простого:

ssh -V

Если вывод показывает версию вида "OpenSSH_for_Windows_9.5p1", клиент на месте. Когда его нет или нужен сервер, обе части добавляются через необязательные компоненты системы. Графический путь проходит через "Параметры", раздел приложений и пункт "Дополнительные компоненты", где находится OpenSSH Client и OpenSSH Server. Второй способ быстрее и подходит для автоматизации:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Удалить компонент можно тем же механизмом с командой Remove-WindowsCapability. Нагрузить чем-то непривычным системы управления конфигурациями это не должно: компонент лежит в локальном хранилище и тянется из Windows Update только при явном отсутствии в офлайн-образе.

После установки серверной части служба sshd появляется в системе, но стартует вручную. Включают её двумя командами:

Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

Правило брандмауэра для порта 22 инсталлятор сервера создаёт сам, однако проверить не помешает: Get-NetFirewallRule -Name ssh. Если порт слушает не тот адрес или конфликтует с чем-то сторонним, всё правится в файле C:\ProgramData\ssh\sshd_config. Этот каталог скрыт от глаз, ведь ProgramData не видна в проводнике без настройки отображения скрытых элементов, но к файлу легко добраться из консоли. После каждой правки конфигурации применяют стандартный цикл: Restart-Service sshd. Внутри файла лежит привычный синтаксис OpenSSH, и почти все директивы, знакомые по Linux-серверам, работают и здесь. Ограничения касаются в основном логики, специфичной для платформы, например делегирования через домен.

Отдельное практическое наблюдение: в давно обновлявшихся системах встречается параллельная поставка через пакет Win32-OpenSSH из старых времён, когда компонент ещё развивался отдельным проектом. Если управление ведётся через сторонний агент, имеет смысл привести estate к единому варианту через нативный компонент, иначе версии становления ключей и поведения sshd начнут разъезжаться между узлами.

Аутентификация по ключам ed25519 и грабля с administrators_authorized_keys

Парольный вход по SSH за пределами доверенной сети считается слабым звеном, поэтому первоочередная работа - настройка ключей. Современный выбор - ed25519: короткие ключи, быстрые операции, устойчивость к атакам на реализацию подписи. Генерация на клиентской машине занимает секунду:

ssh-keygen -t ed25519 -C "admin@workstation"

Утилита попросит путь (по умолчанию C:\Users\Имя\.ssh\id_ed25519) и парольную фразу. Пропускать фразу не стоит: дальше ssh-agent снимет неудобство её постоянного ввода.

Затем публичную часть ключа нужно положить на сервер. На Linux это решает ssh-copy-id, в Windows её нет, но однострочная замена существует:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@host "mkdir .ssh 2>$null; cat >> .ssh/authorized_keys"

Команда выше подходит, когда сервер на Linux. Если sshd работает на Windows, целевой файл живёт в профиле пользователя на той стороне, то есть C:\Users\Имя\.ssh\authorized_keys, и создать его можно локально на сервере или через тот же первичный вход по паролю.

И вот здесь притаилась знаменитая грабля, на которую наступает почти каждый, кто поднимает sshd на Windows впервые. Если вход выполняется под учётной записью, входящей в локальную группу администраторов, сервер игнорирует файл в профиле пользователя! Windows-реализация OpenSSH ищет ключи администраторов в другом месте: C:\ProgramData\ssh\administrators_authorized_keys. Решение принято нарочно, чтобы обычный пользователь, случайно получивший права администратора, не мог сам себе прописать доступ, ведь файл лежит в системном каталоге, защищённом списками контроля доступа.

Практический порядок действий такой:

1. Создать файл C:\ProgramData\ssh\administrators_authorized_keys от имени администратора и вставить туда публичный ключ одной строкой.
2. Проверить и при необходимости поправить права: владельцами должны быть группа Administrators и встроенная учётная запись SYSTEM, остальным доступ закрыт. Утилита sshd сама проверяет это при старте и ругается в журнал событий, если списки доступа слишком широкие.
3. Убедиться, что поведение не отключено в sshd_config: директивы Match Group administrators и AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys должны присутствовать (они добавляются инсталлятором в конце файла по умолчанию).
4. Для обычных, не административных учёток оставить стандартный authorized_keys в профиле пользователя - грабля касается только администраторов.

Типичный симптом этой проблемы выглядит так: ключ на месте, права проверены, а вход всё равно спрашивает пароль. Диагностика ведётся через журнал событий Windows, раздел Applications and Services Logs, OpenSSH, либо запуском sshd в режиме отладки. Когда понимание приходит, лечится всё за минуту, но поиск слепым методом способен съесть вечер.

ssh-agent в Windows и хранение ключей без лишнего ввода

Повторный набор парольной фразы при каждом подключении быстро утомляет, поэтому существует ssh-agent: фоновый процесс, держащий расшифрованный ключ в памяти и отдающий его клиенту по запросу. В Windows агент реализован службой, которая по умолчанию отключена. Включают её так:

Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent

После запуска ключ добавляется одной командой:

ssh-add ~\.ssh\id_ed25519

Фраза запрашивается один раз за сеанс работы агента, и дальше подключения идут молча. Посмотреть загруженные ключи можно через ssh-add -l, а ssh-add -D выгружает всё. Стоит помнить, что агент в Windows привязан к сессии пользователя и сбрасывает ключи при перезагрузке или выходе из системы, так что утренний ритуал добавления ключа остаётся, зато расплачивается он один раз в день.

Полезный приём - forwarding агента через параметр -A или директиву ForwardAgent yes в конфиге: тогда с промежуточного хоста можно прыгать дальше теми же ключами, не копируя их на промежуточный узел. Применять это стоит осознанно: пока соединение открыто, сокет агента на промежуточной машине доступен её суперпользователю. В доверенной лаборатории риск невелик, в общей инфраструктуре лучше обходиться ProxyJump без форвардинга.

Альтернативой файловому хранению служат аппаратные токены: ssh-keygen умеет генерировать ключи типа ecdsa-sk и ed25519 с приставкой -sk, где приватная часть живёт на физическом ключе и не покидает его. На Windows это работает с токенами, поддерживающими FIDO2, и даёт устойчивость к утечке файла с диска.

Проброс портов через ключи -L и -R и динамический форвардинг через -D

Туннели - главная практическая ценность SSH помимо удалённого терминала. Они шифруют поток и пропускают его через единственный разрешённый порт 22, не требуя открытия десятка других портов в периметре.

Локальный проброс -L решает задачу доступа к внутреннему веб-интерфейсу, который слушает приватный адрес и наружу не выставлен. Допустим, на удалённой сети живёт панель управления оборудованием по адресу 10.20.0.15:8080, а попасть туда можно только через прыжковый хост. Команда создаёт локальный порт 9080 на рабочей станции:

ssh -L 9080:10.20.0.15:8080 Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

Пока сессия открыта, обращение в браузере к http://localhost:9080 попадает на внутреннюю панель: SSH-клиент принимает соединение, заворачивает его в шифрованный канал до прыжкового хоста, а тот уже пересылает трафик внутрь. Сам прыжковый хост может вообще не иметь доступа к браузеру - достаточно того, что он маршрутизируется до целевого адреса. Для долгоживущих туннелей добавляют -N (не открывать удалённый шелл) и -f или, на Windows, запуск через Start-Process с параметром WindowStyle Hidden.

Удалённый проброс -R разворачивает направление и позволяет показать наружу локальный сервис. Классический сценарий: разработчик поднял на ноутбуке тестовый экземпляр приложения на порту 3000, а коллега за пределами офиса хочет посмотреть результат. Машина разработчика стучится на внешний сервер и просит слушать порт там:

ssh -R 9000:localhost:3000 Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

Теперь запросы на public.example.net:9000 приходят на ноутбук. Здесь важна директива GatewayPorts в sshd_config на внешнем сервере: по умолчанию -R привязывается к 127.0.0.1 на той стороне, и чтобы порт был виден снаружи, её надо включить осознанно, понимая последствия.

Динамический проброс -D создаёт локальную точку приёма, через которую может идти произвольный TCP-трафик:

команда поднимается ключом -D с указанием локального порта и опорного хоста

Настроив в браузере или другой программе локальный приём TCP на 127.0.0.1:1080, пользователь получает выход в сеть, где живёт прыжковый хост: все запросы адресуются от его имени. Это удобно для административных задач вроде просмотра внутренних ресурсов, доступных только из изолированного сегмента, без поднятия отдельного сервера-посредника. Важно применять приём по регламентам своей инфраструктуры и задокументированных задач администрирования.

Конфиг ~/.ssh/config, псевдонимы и ProxyJump

Когда хостов становится больше пары штук, запоминание длинных строк превращается в наказание. На выручку приходит файл C:\Users\Имя\.ssh\config, который живёт по тому же стандарту, что и на Linux. Фрагмент выглядит так:

Host web
    HostName 192.168.10.25
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host db-internal
    HostName 10.30.5.7
    User dba
    ProxyJump web

Теперь достаточно набрать ssh web или ssh db-internal, и клиент сам подставит адрес, пользователя, ключ и порт. Псевдонимы работают во всех инструментах, опирающихся на OpenSSH: scp, sftp, git при использовании OpenSSH как транспорта, а также в расширениях редакторов.

Блок ProxyJump - самый полезный пример из фрагмента выше. Хост db-internal не имеет прямого маршрута с рабочей станции, но доступен через web. Раньше для этого строили двухэтажные туннели или вызывали ProxyCommand с netcat, а сейчас одна строка решает задачу: клиент сначала открывает сессию на web, затем внутри её канала поднимает второе соединение до конечного узла. Аутентификация проходит локальными ключами на каждом этапе, форвардинг агента не нужен. Цепочку можно удлинять списком через запятую: ProxyJump bastion1,bastion2.

Дополнительно конфигом удобно гасить мелкие раздражители: ServerAliveInterval 60 удерживает сессию от разрыва тайм-аутами NAT, IdentitiesOnly yes запрещает перебор всех ключей из агента (полезно, когда ключей много и сервер ограничивает число попыток), а Include подключает отдельные файлы с настройками под проекты, чтобы не растить мешанину в одном месте.

Встроенные sftp и scp плюс сценарий разработки через удалённый редактор

Передача файлов не требует сторонних клиентов. scp копирует в обе стороны привычным синтаксисом:

scp build.zip deploy@web:/srv/releases/
scp -r deploy@web:/var/log/app ./remote-logs

sftp открывает интерактивный сеанс с командами put, get, ls и рекурсивными операциями, а sftp -b batchfile позволяет прогонять подготовленные сценарии закачки в автоматизации. Оба инструмента используют те же ключи, агент и конфиг, что и ssh, поэтому псевдонимы из предыдущего раздела применимы без дополнительных усилий. Для регулярной синхронизации каталогов на Windows доступен сторонний helper, но для административных задач встроенного инструментария хватает в подавляющем большинстве случаев.

Отдельной строкой стоит сценарий разработчика: популярный редактор кода от известного производителя системы умеет поднимать агента на удалённой машине по простому SSH и работать с файлами там так, словно они локальные. Проект открывается с сервера, терминал внутри редактора живёт на сервере, отладчик цепляется к процессам на сервере, а интерфейс остаётся на рабочей станции и отзывается без задержек оболочки. Настройка сводится к тому же файлу конфига: псевдонимы и ProxyJump из него подхватываются автоматически. Единственное требование - рабочий вход по ключу без интерактива, потому ssh-agent и настроенный config решают практически все вопросы заранее. Для разработчика это превращает мощный сервер в тихую удалённую мастерскую: код, база и runtime живут там, а печатать можно с ноутбука хоть на коленях.

Почему прямой SSH выигрывает у облачных релеев удалённого доступа

На рынке много проприетарных решений удалённого администрирования, построенных по одной схеме: агент на управляемой машине, агент у администратора, а трафик между ними бегает через облачный релей производителя. Схема удобна на старте, но влечёт постоянную плату, зависимость от доступности чужого сервиса и, главное, появление посредника в канале административного доступа. Доверие к такому посреднику должно быть обоснованным, а обосновать его в требованиях по защите инфраструктуры бывает сложно.

SSH работает иначе: клиент соединяется напрямую с узлом или с одним собственным прыжковым хостом, канал шифруется проверенными годами примитивами, журналирование ведётся на собственных серверах, а ключи не покидают инфраструктуру. Прыжковый хост с sshd - это тот же релей, только собственный, под полным контролем, без лицензий за число узлов и без вопроса, кто ещё имеет техническую возможность смотреть на сессии. Для многих команд экономика и безопасность этого варианта очевидны.

Из соображений защиты на поднятом sshd делают несколько шагов. Парольную аутентификацию отключают: PasswordAuthentication no в sshd_config, и вход остаётся только по ключам. Порт 22 при возможности прячут за списками контроля доступа на периметре или переносят на нестандартный номер, что отсекает массовый шум ботов. От переборов ключей и рудиментарных попыток помогает блокировка источников: на Linux эту роль играют известные демоны, а на Windows ближайший аналог - скрипт или небольшая служба, читающая журнал OpenSSH и добавляющая динамические правила брандмауэра; готовые скрипты под это лежат в открытом доступе. Плюс к этому работает журнал событий с политикой аудита входов и периодический пересмотр списка ключей, своевременное удаление доступов уволенных сотрудников и ключи с парольной фразой.

Финальный штрих касается оболочки по умолчанию. При входе по SSH на Windows сервер молча отдаёт cmd.exe, что в век PowerShell выглядит архаикой. Переключение на PowerShell делается одной записью реестра в ветке HKLM\SOFTWARE\OpenSSH: значение DefaultShell с путём к pwsh.exe или powershell.exe. После правки реестра службу sshd перезапускают, и каждая новая сессия открывается сразу в привычной оболочке. Для автоматизации на множестве узлов этот ключ записывается тем же механизмом распространения конфигурации, что и остальные, и административная рутина выравнивается по всей площадке. В сумме получается зрелый инструментарий: нативный клиент и сервер, ключи ed25519 с агентом, туннели под любые задачи, псевдонимы и прыжки через ProxyJump, встроенная передача файлов и прямой шифрованный канал без посредников. Всё это уже лежит в системе и ждёт, когда им начнут пользоваться.