PowerShell Remoting: WinRM и SSH для удалённого управления

Самый быстрый способ включить WinRM со стандартными настройками:

# Включение WinRM (создаёт HTTP-listener на порту 5985)
Enable-PSRemoting -Force

# Проверка конфигурации
winrm get winrm/config
winrm enumerate winrm/config/listener

# Проверка службы
Get-Service WinRM

# Тест подключения
Test-WSMan -ComputerName server01.corp.local

Команда Enable-PSRemoting делает сразу несколько вещей: запускает службу WinRM, ставит её в автозапуск, создаёт HTTP-listener, прописывает исключения в брандмауэре и регистрирует конфигурации сессий PowerShell. Одна строчка — и машина готова к удалённому управлению.

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

# Создание самоподписанного сертификата (для тестов)
$cert = New-SelfSignedCertificate -DnsName "server01.corp.local" `
  -CertStoreLocation Cert:\LocalMachine\My `
  -NotAfter (Get-Date).AddYears(5)

# Создание HTTPS-listener
New-Item WSMan:\localhost\Listener `
  -Transport HTTPS `
  -Address * `
  -CertificateThumbprint $cert.Thumbprint `
  -Force

# Открытие порта в брандмауэре
New-NetFirewallRule -DisplayName "WinRM HTTPS" `
  -Direction Inbound -Protocol TCP `
  -LocalPort 5986 -Action Allow

# Проверка listener'ов
winrm enumerate winrm/config/listener

# Подключение по HTTPS
Enter-PSSession -ComputerName server01.corp.local `
  -UseSSL -Credential (Get-Credential)

В продакшен-среде берите сертификаты от корпоративного CA (Active Directory Certificate Services), а не самоподписанные. Самоподписанные — нормально для тестового стенда, но не для боевой инфраструктуры. Раскатайте сертификаты через групповую политику и забудьте о ручной возне с каждой машиной.

Чтобы настроить WinRM централизованно на всех машинах домена сразу, используйте Group Policy:

# Путь в GPO:
# Computer Configuration → Policies → Administrative Templates →
# Windows Components → Windows Remote Management (WinRM) → WinRM Service

# Ключевые параметры:
# 1. Allow remote server management through WinRM: Enabled
#    IPv4 filter: * (все адреса)
# 2. Allow Basic authentication: Disabled (в доменной среде)
# 3. Allow CredSSP authentication: по необходимости

# Также настройте службу WinRM:
# Computer Configuration → Policies → Windows Settings →
# Security Settings → System Services →
# Windows Remote Management (WS-Management): Automatic

# Брандмауэр через GPO:
# Computer Configuration → Policies → Windows Settings →
# Security Settings → Windows Firewall → Inbound Rules
# Предопределённое правило: Windows Remote Management

На Windows Server 2019 и новее OpenSSH идёт как встроенный компонент — добавлять сторонний софт не нужно:

# Установка OpenSSH Server
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

# Запуск и автозапуск службы
Start-Service sshd
Set-Service sshd -StartupType Automatic

# Брандмауэр
New-NetFirewallRule -DisplayName "OpenSSH Server" `
  -Direction Inbound -Protocol TCP `
  -LocalPort 22 -Action Allow

Чтобы PowerShell Remoting заработал через SSH, нужно зарегистрировать PowerShell как SSH subsystem. Откройте файл C:\ProgramData\ssh\sshd_config и добавьте нужную строку:

# Добавьте строку в sshd_config:
Subsystem powershell c:/progra~1/powershell/7/pwsh.exe -sshs -NoLogo -NoProfile

# Для аутентификации по ключам:
PubkeyAuthentication yes
PasswordAuthentication yes

# Перезапуск SSH
Restart-Service sshd

На Linux-серверах с PowerShell 7 настройка аналогичная, только пути другие:

# /etc/ssh/sshd_config
Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile

# Перезапуск
sudo systemctl restart sshd

Подключение через SSH выглядит так:

# По паролю
Enter-PSSession -HostName linux-srv01.corp.local -UserName admin -SSHTransport

# По ключу
Enter-PSSession -HostName linux-srv01.corp.local `
  -UserName admin `
  -KeyFilePath ~/.ssh/id_rsa `
  -SSHTransport

# Выполнение команд на нескольких серверах (Windows + Linux)
Invoke-Command -HostName server01,linux-srv01,linux-srv02 `
  -UserName admin -SSHTransport `
  -ScriptBlock { Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 }

Если нужно выполнить серию команд на одних и тех же серверах, создайте постоянные сессии заранее — сэкономите время на повторных рукопожатиях:

# Создание сессий ко всем серверам
$servers = Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' |
  Select-Object -ExpandProperty DnsHostName
$sessions = New-PSSession -ComputerName $servers -ThrottleLimit 32

# Выполнение команды на всех серверах параллельно
Invoke-Command -Session $sessions -ScriptBlock {
  [PSCustomObject]@{
    Hostname = $env:COMPUTERNAME
    Uptime   = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
    RAM_Free = [math]::Round((Get-CimInstance Win32_OperatingSystem).FreePhysicalMemory / 1MB, 2)
    CPU_Load = (Get-CimInstance Win32_Processor).LoadPercentage
    Disk_C   = [math]::Round((Get-PSDrive C).Free / 1GB, 2)
  }
} | Sort-Object Hostname | Format-Table -AutoSize

# Копирование файла на все серверы
$sessions | ForEach-Object {
  Copy-Item -Path "C:\Scripts\monitor.ps1" `
    -Destination "C:\Scripts\" -ToSession $_
}

# Закрытие сессий
$sessions | Remove-PSSession

В PowerShell 7 завезли нативную параллелизацию через ForEach-Object -Parallel — выполняете задачи на нескольких серверах одновременно, а не по очереди:

# Параллельная проверка служб на серверах
$servers = @("srv01","srv02","srv03","srv04","srv05")
$servers | ForEach-Object -Parallel {
  Invoke-Command -ComputerName $_ -ScriptBlock {
    Get-Service -Name W3SVC, MSSQLSERVER, WinRM |
      Select-Object @{N='Server';E={$env:COMPUTERNAME}}, Name, Status
  }
} -ThrottleLimit 10 | Format-Table -AutoSize

Сначала создайте файл роли (.psrc), где перечислите разрешённые команды:

# Создание шаблона файла роли
New-PSRoleCapabilityFile -Path "C:\JEA\DNSAdmin.psrc"

# Отредактируйте файл:
@{
  # Модули для импорта
  ModulesToImport = @('DnsServer')

  # Разрешённые командлеты
  VisibleCmdlets = @(
    'Get-DnsServerZone',
    'Get-DnsServerResourceRecord',
    @{ Name = 'Add-DnsServerResourceRecordA';
       Parameters = @{ Name = 'ZoneName'; ValidateSet = 'corp.local' } },
    @{ Name = 'Remove-DnsServerResourceRecord';
       Parameters = @{ Name = 'ZoneName'; ValidateSet = 'corp.local' } }
  )

  # Разрешённые функции
  VisibleFunctions = @('Get-Date', 'Select-Object', 'Format-Table')

  # Разрешённые внешние команды
  VisibleExternalCommands = @('nslookup.exe', 'ipconfig.exe')
}

Затем создайте и зарегистрируйте конфигурацию сессии (.pssc):

# Создание файла конфигурации сессии
New-PSSessionConfigurationFile -Path "C:\JEA\DNSAdmin.pssc" `
  -SessionType RestrictedRemoteServer `
  -RunAsVirtualAccount `
  -RoleDefinitions @{
    'CORP\DNS-Operators' = @{ RoleCapabilities = 'DNSAdmin' }
  } `
  -TranscriptDirectory "C:\JEA\Transcripts"

# Регистрация
Register-PSSessionConfiguration -Name DNSAdmin `
  -Path "C:\JEA\DNSAdmin.pssc" -Force

# Подключение к JEA-сессии
Enter-PSSession -ComputerName dc01.corp.local `
  -ConfigurationName DNSAdmin `
  -Credential (Get-Credential)

# Проверка доступных команд в JEA-сессии
Get-Command

JEA-сессия работает от имени виртуальной учётной записи с правами локального администратора, но сам пользователь запускает только то, что явно разрешено. Каждое действие пишется в Transcript-файлы — потом всегда можно поднять историю и разобраться, что и кто делал.

Классика жанра — проблема double-hop. Подключаетесь к серверу A через remoting, а сервер A уже не может аутентифицироваться на сервере B — например, при обращении к файловой шаре. Учётные данные просто не пробрасываются дальше:

# Вариант 1: CredSSP (менее безопасный)
# На клиенте:
Enable-WSManCredSSP -Role Client -DelegateComputer server01.corp.local
# На сервере:
Enable-WSManCredSSP -Role Server
# Подключение:
Enter-PSSession -ComputerName server01 -Authentication CredSSP -Credential (Get-Credential)

# Вариант 2: Kerberos Constrained Delegation (рекомендуется)
# Настройка через AD:
Set-ADComputer -Identity server01 `
  -PrincipalsAllowedToDelegateToAccount (Get-ADComputer server02)

# Вариант 3: Передача учётных данных через переменную
$cred = Get-Credential
Invoke-Command -ComputerName server01 -ScriptBlock {
  param($c)
  New-PSDrive -Name Z -PSProvider FileSystem `
    -Root "\\fileserver\share" -Credential $c
} -ArgumentList $cred