OpenSSH Server на Windows 11 – штатний SSH-сервер у складі системи. Він дає shell-доступ до ПК у локальній мережі, дозволяє копіювати файли через scp і запускати команди без RDP. Для такого сценарію треба встановити компонент, запустити sshd, додати ключ і обмежити правило у фаєрволі.
Для одного-двох ПК у LAN цього зазвичай вистачає. Якщо доступ потрібен з інтернету, краще одразу будувати VPN, а не відкривати порт 22 на роутері. У Windows SSH ламається в кількох типових місцях: права на authorized_keys, автозапуск служби після ребута і правило firewall без обмеження по підмережі.
Коли варто вмикати SSH на Windows 11
Сценарій простий: потрібен керований доступ до Windows 11 по SSH у локальній мережі. Це зручно для PowerShell, cmd, копіювання логів, швидкого запуску скрипта або перезапуску сервісу з Linux, macOS чи іншої Windows-машини.
Найкраще такий сервер заходить там, де не потрібен повний desktop. Для епізодичного обслуговування штатного компонента вистачає. Одна команда через SSH зазвичай швидша, ніж окрема RDP-сесія.
Коли потрібен доступ до всієї домашньої мережі, картина інша. Для такого сценарію доречніше будувати тунель через WireGuard для віддаленого доступу в домашню мережу, а не відкривати Windows напряму.
Як встановити OpenSSH Server на Windows 11 через Settings і PowerShell
Сервер ставиться як Optional Feature. Через Settings це зручно для одного ПК. PowerShell підходить краще, якщо налаштування треба повторити на кількох машинах.
Встановлення через Settings
- Відкрийте Settings – System – Optional features.
- Натисніть View features.
- Знайдіть OpenSSH Server.
- Виберіть компонент і натисніть Next, потім Install.
Після інсталяції компонент з’явиться у списку встановлених optional features. Але сам сервер ще не приймає підключення. Службу треба запускати окремо.
Встановлення через PowerShell
У PowerShell з правами адміністратора достатньо однієї команди:
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Потім перевірте, що компонент справді встановився:
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'
Статус має бути Installed. Якщо система повертає помилку завантаження capability, проблема часто в оновленнях Windows або політиках, які блокують optional features.
Запуск служби sshd, автозапуск і перевірка порту 22
Після встановлення треба запустити sshd і перевести службу в автоматичний старт. Інакше після ребута доступ зникне. Один статус Running тут не гарантує нічого, тому порт 22 теж варто перевірити окремо.
Запуск служби і автозапуск
У PowerShell з правами адміністратора виконайте:
Start-Service sshd Set-Service -Name sshd -StartupType Automatic
Стан служби перевіряється так:
Get-Service sshd
Очікуваний стан – Running. Якщо потрібен SSH-агент для локальної роботи з ключами на цій самій машині, можна окремо ввімкнути ssh-agent, але для прийому підключень він не потрібен.
Чи справді сервер слухає TCP 22
Перевірка через сокети показує реальний стан краще за список служб. Якщо sshd стартував коректно, у системі з’явиться listener на TCP 22.
netstat -ano | findstr :22
Або через PowerShell:
Get-NetTCPConnection -LocalPort 22 -State Listen
Коли слухача немає, дивитися треба в sshd_config і журнал подій. Типова пастка така: компонент встановлений, але служба не стартує через змінений конфіг або невдалі права на службові файли.
Як налаштувати ключі для OpenSSH Server на Windows 11
Для входу без пароля публічний ключ треба покласти в authorized_keys потрібного користувача. Саме тут OpenSSH Server на Windows 11 найчастіше спотикається: ключ на місці, але сервер його не читає через ACL каталогу або файла.
Створення ключа на клієнтській машині
Якщо ключа ще немає, згенеруйте його на тому ПК, з якого буде підключення:
ssh-keygen -t ed25519
Стандартно пара ключів з’явиться в каталозі ~/.ssh. На клієнті знадобиться файл id_ed25519.pub.
Додавання публічного ключа у Windows 11
На цільовій машині створіть каталог .ssh у профілі користувача, якщо його ще немає. Потім додайте вміст публічного ключа у файл authorized_keys:
mkdir $env:USERPROFILE\.ssh notepad $env:USERPROFILE\.ssh\authorized_keys
Уставте в файл один рядок з вмістом id_ed25519.pub і збережіть його. Для звичайного користувача шлях виглядає так: C:\Users\<username>\.ssh\authorized_keys.
Що змінити в sshd_config
У більшості випадків базова конфігурація вже підтримує ключі. Якщо треба вимкнути парольний вхід, відредагуйте файл C:\ProgramData\ssh\sshd_config і перевірте такі параметри:
PubkeyAuthentication yes PasswordAuthentication no
Після зміни конфіга службу треба перезапустити:
Restart-Service sshd
Парольний вхід краще вимикати лише після перевірки ключа. Інакше доступ легко закрити одним невдалим редагуванням.
Чому authorized_keys часто ігнорується
Файл має належати користувачу, під яким виконується вхід, і не повинен бути надто відкритим. Якщо ключ ігнорується без очевидної причини, насамперед перевіряють ACL на .ssh і authorized_keys. У Windows це трапляється частіше, ніж помилка в самому ключі.
Яке правило у Windows Firewall лишити тільки для LAN
Для безпечного доступу в локальній мережі TCP 22 краще відкрити лише для свого сегмента. Найгірший варіант тут – правило Any по remote address і проброс порту на роутері. Так система стає видимою значно ширше, ніж потрібно.
Перевірка готового правила
Після встановлення сервер часто створює базове правило у Windows Firewall. Його варто не лише ввімкнути, а й перевірити область дії:
Get-NetFirewallRule -Name *OpenSSH* | Get-NetFirewallAddressFilter
Якщо адреси не обмежені, правило краще перевизначити окремо.
Створення правила для локальної підмережі
Для типової домашньої мережі з підмережею 192.168.1.0/24 підійде така команда:
New-NetFirewallRule -Name "OpenSSH-Server-LAN" -DisplayName "OpenSSH Server LAN" -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 -RemoteAddress 192.168.1.0/24
Якщо мережа інша, змініть RemoteAddress на свій сегмент. Для кількох підмереж їх можна перелічити через кому. До 2-3 сегментів це ще читається нормально, далі простіше переглянути схему доступу, ніж роздувати винятки.
Коли SSH потрібен час від часу і немає бажання чіпати маршрутизатор, існує окремий підхід через тунель. У матеріалі про обмеження доступу до SSH без відкриття портів логіка вибору та сама: менше exposed-сервісів, менше зайвих точок входу.
Як підключитися по SSH і перевірити результат
Для перевірки потрібні IP-адреса Windows 11 у локальній мережі та обліковий запис, під яким дозволено вхід. Якщо все зібрано правильно, сесія відкриється з іншого ПК без затримок і без запиту пароля, коли налаштовано ключ.
Команда підключення
На іншому ПК у тій самій мережі виконайте:
ssh <username>@<windows-ip>
Для входу конкретним ключем:
ssh -i ~/.ssh/id_ed25519 <username>@<windows-ip>
Під час першого підключення клієнт попросить підтвердити host key. Після входу корисно одразу перевірити, який shell відкрився, і чи є доступ до потрібних шляхів та команд.
Що перевірити після входу
- Виконується
whoamiі повертає очікуваного користувача. - Працює перехід у потрібні каталоги.
scpкопіює невеликий файл без помилок.- Після перепідключення пароль не запитується, якщо вхід по ключу вже ввімкнено.
IP-адресу Windows 11 можна дізнатися командою ipconfig. Якщо ПК спить, SSH не відповість навіть при справній службі. Для домашньої машини тут часто потрібен окремий сценарій з Wake-on-LAN для домашнього ПК.
Чому сервер не пускає по ключу або не стартує після перезавантаження
Найчастіші збої зводяться до трьох речей: sshd не в автозапуску, firewall пускає не з тієї мережі або authorized_keys має невдалі права. Якщо OpenSSH Server на Windows 11 встановлено, але вхід не працює, перевіряти ці точки варто саме в такому порядку.
Ключ є, але система просить пароль
Зазвичай сервер не читає authorized_keys. Або файл лежить не в профілі того користувача, або в нього невдалі ACL, або в sshd_config лишився дозволений парольний вхід і клієнт тихо переходить на нього.
Ще одна часта помилка – зайві переноси рядка або пробіли на початку ключа. Для authorized_keys це критично. Один ключ має бути одним рядком.
Служба працювала, а після ребута доступу немає
Першою перевіряють опцію StartupType. Якщо вона не Automatic, сервер сам не стартує. Друга типова точка відмови – ручне редагування sshd_config з помилкою синтаксису.
Для перевірки достатньо таких команд:
Get-Service sshd Get-NetTCPConnection -LocalPort 22 -State Listen
Порт 22 не відповідає з іншого ПК
Якщо локально listener є, а з мережі підключення немає, дивитися треба на Windows Firewall і мережевий профіль адаптера. Правило може бути прив’язане лише до Private, а інтерфейс опинився в Public. Після перевстановлення драйвера або зміни адаптера таке трапляється регулярно.
Ще одна перевірка – чи підключення йде саме в актуальну LAN-адресу, а не в старий DHCP-ліз. Для ПК без статичної адреси SSH на Windows швидко стає дратівливим, якщо IP постійно змінюється. Тут допомагає або DHCP reservation, або hostname через локальний DNS.
Коли достатньо SSH, а коли вже потрібен VPN
SSH у локальній мережі достатній, коли потрібен shell-доступ до конкретного ПК, кілька команд і передача файлів без виходу в інтернет. Якщо ж доступ має працювати ззовні дому, для кількох пристроїв і без відкритих портів, безпечніше підняти VPN.
Для одного Windows-ПК у LAN схема з sshd, ключами й правилом на одну підмережу закриває задачу без зайвої складності. До певного масштабу це зручніше за окремі агенти керування. Межа починається там, де потрібен доступ до NAS, гіпервізора, контейнерів, роутера, камер або кількох VLAN.
Тоді SSH перетворюється на набір окремих винятків, якими незручно керувати. Для такого випадку доречно подивитися порівняння Tailscale і WireGuard і вибрати схему, яка закриє весь сегмент, а не один хост.
Документацію Microsoft по OpenSSH for Windows зручно тримати під рукою для перевірки параметрів sshd_config і поведінки служби: OpenSSH for Windows overview.
Коментарі
Коментарів ще немає. Обговорення - у Telegram.