SSH w Windows - instalacja, klucze i bezpieczny dostęp

Praca z komputerem z Windows nie zawsze wymaga pulpitu zdalnego. Gdy wystarczy uruchomić polecenie, wdrożyć aplikację .NET albo sprawdzić usługę, SSH w Windows daje szybki i bezpieczny dostęp z terminala. Pokażę, jak włączyć klienta i serwer OpenSSH, skonfigurować logowanie kluczem, wykonywać polecenia zdalnie oraz rozwiązać problemy z usługą, zaporą i uprawnieniami.

Czym jest SSH w Windows i kiedy naprawdę się przydaje

SSH, czyli Secure Shell, tworzy szyfrowane połączenie między klientem a komputerem pełniącym rolę serwera. Po uwierzytelnieniu dostaję zdalny terminal, w którym mogę uruchamiać polecenia, zarządzać usługami, kopiować pliki i wykonywać skrypty. Najważniejsza korzyść to brak konieczności otwierania całego pulpitu.

W praktyce najczęściej korzystam z tego rozwiązania przy administracji serwerem Windows, pracy z maszyną w Azure, automatyzacji wdrożeń oraz obsłudze aplikacji .NET. SSH dobrze sprawdza się również wtedy, gdy z komputera z Linuxem lub macOS trzeba szybko wykonać polecenie na stacji roboczej z Windows.

Trzeba jednak od razu rozdzielić dwie rzeczy. OpenSSH Client pozwala inicjować połączenia, natomiast OpenSSH Server uruchamia usługę nasłuchującą na komputerze, do którego chcemy się dostać. Na przykład laptop może mieć tylko klienta, a serwer testowy powinien mieć klienta i serwer.

Jeżeli aplikacja ma interfejs graficzny, samo SSH jej nie pokaże. Można wprawdzie uruchomić proces zdalnie, ale okno pozostanie związane z sesją użytkownika i nie zachowa się jak pulpit dostępny przez RDP. To ograniczenie często wychodzi dopiero po konfiguracji, dlatego dobrze uwzględnić je przed wyborem narzędzia.

Jak zainstalować klienta i serwer OpenSSH

Najwygodniej zacząć od sprawdzenia dostępnych komponentów. Otwieram PowerShell jako administrator i wykonuję:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'

Stan Installed oznacza, że komponent jest już dostępny. Jeśli potrzebuję tylko łączyć się z innymi komputerami, wystarczy klient. Gdy chcę wpuszczać połączenia na bieżący komputer, instaluję także serwer:

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

Po instalacji uruchamiam usługę sshd i ustawiam jej automatyczny start. Dzięki temu serwer będzie dostępny także po restarcie systemu:

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

Instalator zwykle dodaje regułę zapory OpenSSH-Server-In-TCP, która otwiera port 22. Nie zakładam jednak, że reguła na pewno istnieje, szczególnie na komputerze z wcześniejszymi zmianami zasad bezpieczeństwa. Sprawdzam ją poleceniem:

Get-NetFirewallRule -Name OpenSSH-Server-In-TCP -ErrorAction SilentlyContinue

Jeśli reguły nie ma, można utworzyć ją ręcznie:

New-NetFirewallRule `
  -Name OpenSSH-Server-In-TCP `
  -DisplayName "OpenSSH Server (sshd)" `
  -Enabled True `
  -Direction Inbound `
  -Protocol TCP `
  -Action Allow `
  -LocalPort 22

Na tym etapie serwer powinien już działać, ale nie oznacza to jeszcze, że jest dobrze zabezpieczony. W środowisku firmowym ograniczam regułę zapory do konkretnej podsieci albo adresów administracyjnych. Otwarcie portu 22 na cały internet bez dodatkowych zabezpieczeń to proszenie się o próby logowania.

Jak połączyć się z komputerem z Windows

Z drugiego komputera używam polecenia ssh w formacie:

ssh nazwa_uzytkownika@adres_komputera

Przykładowe połączenie może wyglądać tak:

ssh dev@192.168.1.50

Przy pierwszym połączeniu klient wyświetli odcisk klucza hosta. Weryfikuję go z administratorem albo z konsoli serwera, zamiast bezmyślnie potwierdzać komunikat. To zabezpiecza przed sytuacją, w której ruch został przechwycony i skierowany do innej maszyny.

Jeżeli serwer działa na innym porcie, dodaję parametr -p:

ssh -p 2222 dev@192.168.1.50

Po zalogowaniu domyślną powłoką może być cmd.exe. Windows OpenSSH pozwala zmienić ją na PowerShell, ustawiając wartość DefaultShell w rejestrze pod ścieżką HKLM\SOFTWARE\OpenSSH. Robię to tylko wtedy, gdy wszyscy użytkownicy serwera rzeczywiście potrzebują PowerShella, ponieważ zmiana wpływa na sposób działania kolejnych sesji.

New-ItemProperty `
  -Path "HKLM:\SOFTWARE\OpenSSH" `
  -Name "DefaultShell" `
  -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" `
  -PropertyType String `
  -Force

SSH przydaje się także bez otwierania interaktywnego terminala. Poniższe polecenie uruchamia zdalnie sprawdzenie usługi:

ssh dev@192.168.1.50 "Get-Service sshd"

W podobny sposób można wykonać skrypt wdrożeniowy, sprawdzić proces aplikacji albo odczytać logi. W automatyzacji unikam jednak wpisywania haseł w skryptach. Do tego celu znacznie lepiej nadają się klucze SSH i agent kluczy.

Logowanie kluczem i rozsądne zabezpieczenie usługi

Para kluczy składa się z klucza prywatnego i publicznego. Prywatny pozostaje na komputerze klienta, a publiczny trafia na serwer. Sam klucz publiczny nie daje dostępu, ale klucz prywatny należy chronić tak jak hasło administratora, najlepiej za pomocą hasła ochronnego, czyli passphrase.

Na komputerze klienckim generuję klucz Ed25519:

ssh-keygen -t ed25519 -C "dev@windows-client"

Powstaną zwykle pliki w katalogu C:\Users\\.ssh. Plik z rozszerzeniem .pub można przekazać na serwer. Klucz prywatny bez rozszerzenia pozostaje wyłącznie na komputerze klienta i nie powinien trafiać do repozytorium, współdzielonego dysku ani załącznika wiadomości.

W systemach Linux często używa się ssh-copy-id, ale w Windows można skopiować zawartość klucza publicznego ręcznie. Dla zwykłego konta użytkownika właściwym miejscem jest:

C:\Users\dev\.ssh\authorized_keys

Dla kont należących do lokalnej grupy administratorów Windows OpenSSH może korzystać ze wspólnego pliku:

C:\ProgramData\ssh\administrators_authorized_keys

Ten drugi plik wymaga poprawnych uprawnień NTFS. Przykładowa konfiguracja ogranicza dostęp do grupy Administratorzy i konta SYSTEM:

icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" `
  /inheritance:r `
  /grant "Administrators:F" `
  /grant "SYSTEM:F"

Po skopiowaniu klucza testuję logowanie w nowej sesji. Dopiero gdy działa bez zarzutu, rozważam zmianę konfiguracji w C:\ProgramData\ssh\sshd_config. Można ograniczyć dostęp do wybranych kont lub grup, na przykład:

AllowGroups sshusers
AllowUsers dev

Zmiany konfiguracji wymagają ponownego uruchomienia usługi:

sshd -t
Restart-Service sshd

Polecenie sshd -t sprawdza składnię przed restartem. To drobny krok, który oszczędza dużo nerwów, bo literówka w konfiguracji może odciąć dostęp do serwera. Hasłowe logowanie wyłączam dopiero po sprawdzeniu klucza, dostępu awaryjnego i działania wszystkich kont administracyjnych.

SSH w pracy z aplikacjami desktopowymi i .NET

W przypadku aplikacji desktopowych SSH najlepiej traktować jako kanał administracyjny, a nie zamiennik pulpitu. Mogę przez niego uruchomić instalator w trybie cichym, sprawdzić wersję środowiska .NET, zmienić plik konfiguracyjny albo zrestartować usługę, ale nie otrzymam wygodnego widoku okien aplikacji.

Przykładowy zestaw poleceń pozwala szybko zweryfikować środowisko na maszynie zdalnej:

ssh dev@192.168.1.50 "dotnet --info"
ssh dev@192.168.1.50 "Get-Process MyApp"
ssh dev@192.168.1.50 "Get-Service MyAppService"

Do przesyłania paczek wdrożeniowych można użyć scp:

scp .\publish.zip dev@192.168.1.50:C:\Deploy\publish.zip

Przy większej liczbie plików wygodniejszy bywa SFTP, ponieważ pozwala przeglądać katalogi i kopiować dane w sposób bardziej kontrolowany. W obu przypadkach transfer jest szyfrowany, ale samo SSH nie zastępuje procesu wdrożeniowego. Nadal trzeba zadbać o wersjonowanie, kopie zapasowe, uprawnienia katalogów i możliwość wycofania zmiany.

Jeśli aplikacja desktopowa wymaga interakcji z użytkownikiem, sterownika albo dostępu do konkretnej sesji graficznej, wybieram RDP lub narzędzie do zdalnego pulpitu. SSH zostawiam do zadań powtarzalnych, skryptowych i administracyjnych. To rozróżnienie w praktyce jest ważniejsze niż sama instalacja serwera.

Co sprawdzić, gdy połączenie nie działa

Najpierw ustalam, na którym etapie pojawia się problem. Z komputera klienckiego sprawdzam dostępność portu:

Test-NetConnection 192.168.1.50 -Port 22

Wynik TcpTestSucceeded : False wskazuje zwykle na zatrzymaną usługę, zaporę, błędny adres albo filtr sieciowy. Jeśli port odpowiada, ale logowanie się nie udaje, uruchamiam klienta w trybie diagnostycznym:

ssh -vvv dev@192.168.1.50

Najczęstsze przyczyny są dość powtarzalne:

• Usługa sshd jest zatrzymana, więc sprawdzam Get-Service sshd i uruchamiam ją ponownie.
• Zapora blokuje port, mimo że sama usługa działa.
• Używam złej nazwy konta. Dla kont lokalnych trzeba wskazać właściwego użytkownika, a dla domenowych czasem użyć formatu domenowego.
• Klucz ma złe uprawnienia albo leży w niewłaściwym pliku.
• Edytowany był inny plik konfiguracyjny niż domyślny C:\ProgramData\ssh\sshd_config.
• Po zmianie konfiguracji nie zrestartowano usługi.

Logi są dostępne w Podglądzie zdarzeń, a przy konfiguracji logowania plikowego mogą pojawić się w katalogu C:\ProgramData\ssh\logs. Nie zmieniam kilku rzeczy naraz. Najpierw sprawdzam sieć, potem usługę, uwierzytelnianie i dopiero na końcu uprawnienia. Taka kolejność szybko pokazuje, czy problem leży po stronie transportu, czy samego konta.

Jak ułożyć bezpieczny model dostępu

Najprostszy model, który sprawdza się w małym środowisku, to osobne konto do administracji, logowanie kluczem Ed25519, ograniczenie reguły zapory do sieci zarządzającej i dostęp tylko do potrzebnej grupy. Nie wystawiam SSH bezpośrednio do internetu, jeśli mogę użyć VPN, prywatnego adresu albo bezpiecznego bastionu.

Port 22 można zmienić, ale nie traktuję tego jako zabezpieczenia. Zmiana portu ogranicza część automatycznych skanów, lecz nie zastępuje kluczy, zapory, aktualizacji i monitorowania logowań. Znacznie większą różnicę robi wyłączenie słabych kont, ograniczenie źródeł ruchu i regularne sprawdzanie, kto ma dostęp.

W środowisku domenowym dochodzi jeszcze kwestia sposobu uwierzytelniania. Windows OpenSSH obsługuje konta lokalne i konta Active Directory, ale logowanie kluczem dla kont Microsoft Entra ID nie jest obsługiwane. Jeśli organizacja korzysta głównie z Entra ID, trzeba zaplanować inny mechanizm dostępu, na przykład Azure Bastion, RDP z odpowiednią kontrolą tożsamości albo zarządzanie przez narzędzia chmurowe.

Przed wdrożeniem sprawdzam także, czy sesja SSH nie potrzebuje delegowania poświadczeń do kolejnego serwera. Sesja uwierzytelniona kluczem nie zawsze ma poświadczenia użytkownika, które można wykorzystać do dalszego logowania. To typowy przypadek, gdy skrypt działa lokalnie, ale po uruchomieniu przez SSH nie może odczytać zasobu sieciowego.

Dobry punkt startowy do administracji Windows z terminala

SSH w Windows ma największy sens wtedy, gdy chcę powtarzalnie wykonywać konkretne zadania: wdrażać aplikację, sprawdzać procesy, restartować usługi, kopiować pliki albo zarządzać serwerem bez uruchamiania całego pulpitu. Konfiguracja nie jest trudna, ale bezpieczeństwo zależy od szczegółów, szczególnie klucza prywatnego, uprawnień pliku i zakresu reguły zapory.

Moja praktyczna kolejność jest prosta. Najpierw instaluję klienta lub serwer, testuję usługę i port, potem konfiguruję klucz, ograniczam dostęp do wybranych użytkowników, a dopiero na końcu wyłączam logowanie hasłem. Taki proces daje wygodny dostęp administracyjny bez tworzenia sobie problemu z usługą wystawioną szerzej, niż rzeczywiście potrzeba.