PowerShell Remoting через WinRM или SSH: какой транспорт выбрать и как настроить

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет работы с Windows-инфраструктурами я видел эволюцию PowerShell Remoting: сначала только WinRM, потом PowerShell 6 принёс SSH-транспорт, а с PowerShell 7 SSH-remoting стал боевым вариантом. У нас на практике я сам выбираю транспорт под задачу: гибридные парки Windows+Linux — SSH, чистый AD-домен с 200 серверами — WinRM, централизованный jump-host с авторизацией по ключам — тоже SSH. В этой статье — сравнение транспортов, реальные команды настройки и рекомендации, когда выбирать что.

Исторический контекст

WinRM появился в Windows Server 2008 и стал основой Windows-remoting. SSH в мире Windows долго был экзотикой: ставили Cygwin или OpenSSH от третьих лиц. С Windows 10 v1803 Microsoft включила OpenSSH как компонент (Features on Demand), а в PowerShell 6 добавила SSH-транспорт для remoting. Сегодня SSH работает нативно и на Windows Server 2019+, и на десктопных Windows 11.

Сравнение транспортов

Мой главный критерий выбора: если инфраструктура чистого Windows AD — оставляю WinRM, потому что Kerberos и JEA дают лучший security profile. Если есть Linux или Docker-хосты и нужен единый инструмент для всех — ставлю PowerShell 7 и использую SSH.

Установка OpenSSH Server на Windows

# Windows Server 2019+, Windows 10/11
Get-WindowsCapability -Online -Name OpenSSH* | Where-Object State -eq 'NotPresent' |
    Add-WindowsCapability -Online

# Запуск и автостарт
Set-Service -Name sshd -StartupType Automatic
Start-Service sshd

# Firewall
New-NetFirewallRule -Name 'SSH-In' -DisplayName 'OpenSSH Server (sshd)' `
    -Protocol TCP -LocalPort 22 -Direction Inbound -Action Allow

# Проверка
Get-Service sshd, ssh-agent
netstat -an | Select-String ':22 '

Настройка sshd_config для PowerShell Subsystem

Чтобы SSH-клиент понимал, куда писать в PowerShell, нужно добавить subsystem. Файл C:\ProgramData\ssh\sshd_config:

# Разрешить вход по ключу
PubkeyAuthentication yes
PasswordAuthentication yes     # можно отключить после настройки ключей

# Subsystem для PowerShell 7
Subsystem powershell c:/progra~1/powershell/7/pwsh.exe -sshs -NoLogo

# Отключить GSSAPI если не используется Kerberos
GSSAPIAuthentication no

# Ограничить пользователей
AllowGroups 'Administrators' 'Remote Management Users'

После правки — Restart-Service sshd. Теперь с клиента:

Enter-PSSession -HostName srv-app01 -UserName admin -SSHTransport
Invoke-Command -HostName srv-app01 -UserName admin -ScriptBlock { hostname; $PSVersionTable.PSVersion }

Аутентификация по ключам

Пароли — плохо. Ключи — хорошо. Генерируем на клиенте:

ssh-keygen -t ed25519 -f $HOME\.ssh\id_corp
# Получили id_corp (приватный) и id_corp.pub (публичный)

# Копируем публичный на сервер
# Вариант 1: автоматом, если sshd настроен и пароль работает
ssh-copy-id.exe -i $HOME\.ssh\id_corp.pub admin@srv-app01

# Вариант 2: руками через RDP / Invoke-Command
$pub = Get-Content $HOME\.ssh\id_corp.pub
Invoke-Command srv-app01 -ScriptBlock {
    Add-Content -Path $env:USERPROFILE\.ssh\authorized_keys -Value $using:pub
}

Важно: на Windows есть нюанс с правами на файл authorized_keys — он должен принадлежать только пользователю или системе, иначе OpenSSH его проигнорирует. Для админских аккаунтов используется отдельный файл C:\ProgramData\ssh\administrators_authorized_keys.

Remoting между Windows и Linux

Основной сценарий, ради которого я вообще начал использовать SSH-remoting — управление смешанным парком. У одного клиента 45 Linux-серверов (Ubuntu 22.04) и 30 Windows. Ansible уже стоит, но хочется интерактивного Enter-PSSession. Настройка на Linux:

sudo apt install powershell openssh-server -y
# В /etc/ssh/sshd_config
# Subsystem powershell /usr/bin/pwsh -sshs -NoLogo

sudo systemctl restart ssh

С Windows-клиента:

Enter-PSSession -HostName ubuntu-app01 -UserName devops -SSHTransport
# Получаем PowerShell на Linux
PS /home/devops> Get-Process | Sort-Object CPU -Descending | Select-Object -First 5

Мини-кейс: гибридная инфраструктура

В декабре 2025 взяли в обслуживание клиента — IT-компанию (70 Windows + 40 Linux, 280 рабочих мест). У них был хаос: Windows-сервера через RDP, Linux через SSH, пароли везде разные, никакой централизации. Менеджмент попросил унификации. Решение:

• Подняли два jump-host в разных дата-центрах на Dell с Xeon Platinum 8280, 64 ГБ RAM, 40G Mellanox в кольцо между площадками. Основной хостинг — дата-центр МТС.
• На всех Windows-серверах установили PowerShell 7 и OpenSSH Server.
• На всех Linux-серверах установили PowerShell 7.
• Настроили SSH-CA с короткоживущими сертификатами (8 часов). Админ получает сертификат после 2FA, с ним ходит по серверам.
• WinRM остался только для работы с JEA и для сценариев CIM (Get-CimInstance быстрее через WinRM).
• Все PSSession автоматически логируются в Grafana Loki через syslog/Windows Event Forwarding.

Результат: любой инженер может одной командой подключиться к любому серверу парка — Windows или Linux — из PowerShell 7. Пароли нигде не хранятся. Средний MTTR упал с 40 минут до 18. Стоимость внедрения — 180 тыс. руб.

Производительность и нюансы

Несколько практических наблюдений:

• Первое подключение по SSH медленнее WinRM из-за handshake ключей. Последующие — быстрее за счёт ControlMaster/ControlPath в ~/.ssh/config.
• WinRM через PSSession умеет держать постоянную сессию лучше — через $session = New-PSSession и переиспользование.
• Массовый Invoke-Command на 100+ серверов: WinRM сильно быстрее SSH благодаря нативному пулу и Kerberos.
• Get-CimInstance по SSH не работает — только по WinRM. Если нужно читать WMI, выбирайте WinRM.
• Большие данные (файлы > 100 МБ) лучше передавать через SMB/SCP, а не Invoke-Command — remoting имеет ограничение на размер сообщения.

ControlMaster для ускорения SSH

Файл ~/.ssh/config на клиенте:

Host *.corp.itfresh.local
    User svc_ops
    IdentityFile ~/.ssh/id_corp
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 10m
    ServerAliveInterval 30
    ServerAliveCountMax 3

Первое подключение открывает мастер-соединение, следующие — мультиплексируются через него. Второй Enter-PSSession на тот же хост открывается за доли секунды.

Безопасность

По пунктам:

• PasswordAuthentication no — только ключи или SSH-CA.
• Ограничить AllowUsers/AllowGroups — не оставляйте *.
• DenyUsers с root и common-именами (administrator) — лишняя, но иногда помогает.
• PermitRootLogin no — админские подключения под именованной учёткой.
• SSH-CA с short-living сертификатами — самая надёжная схема для корпоратива.
• Fail2ban или Windows Defender Firewall с алертом при брутфорсе.
• Логи /var/log/auth.log (Linux) или Microsoft-Windows-OpenSSH/Operational (Windows) — в SIEM.

Когда оставлять WinRM

• Полностью Windows AD-домен 50+ серверов — Kerberos быстрее и проще.
• Нужны JEA-роли — SSH их не поддерживает.
• Работаете с CIM/WMI через Get-CimInstance, Get-WmiObject.
• Используется DSC Pull Server — он на WinRM.
• Интеграции со SCOM, SCVMM, WAC.

FAQ — частые вопросы о WinRM и SSH

Когда выбирать SSH вместо WinRM?

Когда у вас смешанный парк Windows+Linux и хочется единый инструмент. Когда целевой хост не в домене. Когда нужна аутентификация по ключам, а не паролям или сертификатам. Когда управляете из macOS/Linux в Windows.

Можно ли Enter-PSSession через SSH?

Да, начиная с PowerShell 6. Enter-PSSession -HostName srv01 -UserName user -SSHTransport. Предварительно нужно установить OpenSSH Server на целевую машину и настроить Subsystem powershell в sshd_config.

Поддерживает ли SSH-remoting JEA?

Нет. JEA — функция WinRM, через SSH пока недоступна. Если нужны JEA-роли, оставайтесь на WinRM или используйте ограничения на уровне OpenSSH (ForceCommand, match user).

Какая версия PowerShell нужна для SSH?

PowerShell 7.x на обоих концах. Windows PowerShell 5.1 не поддерживает SSH-транспорт. OpenSSH Server — компонент Windows 10/11 и Server 2019+.

Какой транспорт быстрее?

Для одиночных Invoke-Command — примерно одинаково. Для массовых — WinRM в AD-домене быстрее за счёт Kerberos tickets. SSH медленнее на первой аутентификации, но может удерживать session через ControlMaster.