Połączenie z serwerem przez SSH: Windows, macOS i Linux

Świeżo zamówiony serwer przychodzi bez monitora i bez klawiatury. Jedyna droga do środka prowadzi przez SSH, czyli protokół Secure Shell. Ten artykuł przeprowadzi cię przez pierwsze połączenie z trzech systemów operacyjnych, wyjaśni pytanie o odcisk palca (prawie wszyscy początkujący klikają je na ślepo) i pokaże, jak przesyłać pliki. Na końcu znajdziesz część, którą większość poradników pomija: co robić, kiedy nie działa, i po czym poznasz, że naprawdę zadziałało.

Wszystkie informacje zostały sprawdzone na Debianie 13, Debianie 12, Ubuntu 24.04 LTS oraz Ubuntu 22.04 LTS. Tam, gdzie te cztery systemy się różnią, jest to wyraźnie zaznaczone. Polecenia na serwerze wykonujesz jako root. Na własnym komputerze pracujesz natomiast na zwykłym koncie użytkownika, dlatego przed każdym poleceniem zmieniającym system stoi tam sudo.

Co jest ci potrzebne przed pierwszym połączeniem

Wystarczą trzy informacje: adres IP serwera, nazwa użytkownika oraz hasło albo klucz prywatny. W KernelHoście adres IP i dane logowania znajdziesz po uruchomieniu usługi w panelu klienta. Domyślnym użytkownikiem na świeżo zainstalowanym serwerze root KVM albo serwerze dedykowanym jest z reguły root.

Jako czwarta dochodzi informacja o porcie. Domyślnie jest to 22. Innej liczby potrzebujesz tylko wtedy, gdy sam go zmieniłeś albo przeniósł go obraz systemu. Zapamiętaj już teraz pułapkę, która później oszczędzi ci czasu: ssh zapisuje port małą literą (-p), a scp wielką (-P).

W przykładach konsekwentnie występuje 203.0.113.10. Ten adres jest oficjalnie zarezerwowany do dokumentacji i nie istnieje. Zastąp go adresem IP swojego serwera.

Pierwsze połączenie w systemach Linux i macOS

Oba systemy mają klienta OpenSSH na pokładzie. W macOS otwierasz Terminal (w folderze Narzędzia), w Linuksie dowolne okno terminala. Polecenie jest na obu takie samo:

ssh root@203.0.113.10

Jeśli SSH działa na innym porcie:

ssh -p 2222 root@203.0.113.10

Jeśli twój system nie zna polecenia ssh, co zdarza się przy bardzo odchudzonych instalacjach kontenerowych albo minimalnych, sprawdzasz je i instalujesz tak:

ssh -V
sudo apt update
apt-cache policy openssh-client
sudo apt install -y openssh-client

Kolejność nie jest przypadkowa. ssh -V to polecenie kontrolne, a nie dowód powodzenia: jeśli powłoka odpowie bash: ssh: command not found, brakuje pakietu openssh-client i doinstalujesz go poleceniem sudo apt install -y openssh-client. sudo apt update należy wykonać przed apt-cache policy openssh-client, bo bez wczytanych list pakietów to polecenie nic nie zwróci albo zgłosi tylko Installed: (none). A sudo nie jest ozdobnikiem: bez uprawnień administratora apt przerywa pracę komunikatem Could not open lock file /var/lib/apt/lists/lock.

ssh -V wypisuje wersję na wyjście błędów, a nie na wyjście standardowe. To nie usterka, tylko zachowanie znane od zawsze. Na Debianie 13 zobaczysz OpenSSH_10.0p2, na Debianie 12 OpenSSH_9.2p1, na Ubuntu 24.04 OpenSSH_9.6p1, a na Ubuntu 22.04 OpenSSH_8.9p1. Te liczby będą ważne dalej, bo zachowanie scp zmieniło się dokładnie pomiędzy tymi wersjami.

Odcisk palca i dlaczego nie warto go zatwierdzać bez zastanowienia

Przy pierwszej próbie połączenia SSH pyta:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Co się tutaj dzieje: każdy serwer SSH generuje podczas instalacji własną parę kluczy, tak zwany host key. Odcisk palca to krótka suma kontrolna części publicznej. Twój klient nie zna jeszcze tego serwera i dlatego nie może zagwarantować, że po drugiej stronie siedzi naprawdę twój serwer, a nie ktoś, kto wpiął się po drodze.

Jeśli wpiszesz yes, odcisk palca zostanie zapisany w ~/.ssh/known_hosts. Od tej chwili twój klient przy każdym kolejnym połączeniu po cichu sprawdza, czy serwer pokazuje ten sam klucz. To jedno pytanie jest więc momentem, w którym buduje się cały model zaufania. Potem nikt już o nic nie zapyta.

Porządnie sprawdzisz go tylko drugą, niezależną drogą. Przy serwerze KVM najlepiej nadaje się konsola w panelu klienta: logujesz się tam lokalnie, całkowicie bez sieci, i wyświetlasz sobie odcisk palca.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Wynik wygląda tak:

256 SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU root@server (ED25519)

Jeśli część za SHA256: zgadza się z tym, co pokazuje twój klient, wszystko jest w porządku. Gdy chcesz bezpiecznie poćwiczyć na samym formacie, wygeneruj sobie lokalnie klucz jednorazowy:

ssh-keygen -t ed25519 -f /tmp/demo -N "" -C demo
ssh-keygen -lf /tmp/demo.pub

Dwie uwagi z praktyki. Po pierwsze: serwer ma zwykle kilka host keys (ED25519, ECDSA, RSA). Wyświetlany jest przeważnie klucz ED25519, bo współczesne klienty właśnie ten preferują. Jeśli przez pomyłkę porównasz go z ssh_host_rsa_key.pub, nic się nie będzie zgadzać, chociaż wszystko jest poprawne. Po drugie: StrictHostKeyChecking=no wyłącza sprawdzanie całkowicie i nie jest żadnym rozwiązaniem, tylko wyłączeniem funkcji bezpieczeństwa. Gdy potrzebujesz automatyzacji, właściwym wyborem jest -o StrictHostKeyChecking=accept-new: akceptuje nieznane serwery automatycznie, ale nadal ostrzega przy zmianach.

Windows: wbudowany klient OpenSSH

Od Windowsa 10 w wersji 1809 Microsoft dostarcza tego samego klienta OpenSSH, którego używają Linux i macOS. Nie potrzebujesz więc już żadnego dodatkowego programu. Otwórz PowerShell, wiersz polecenia albo Windows Terminal i wpisz to samo polecenie, co wyżej:

ssh root@203.0.113.10

W Windows 10 i Windows 11 klient jest składnikiem opcjonalnym, który w większości instalacji jest już aktywny. Jeśli nie, sprawdzisz go i zainstalujesz w PowerShellu uruchomionym z uprawnieniami administratora:

Get-WindowsCapability -Online -Name OpenSSH.Client*
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Alternatywnie przez Ustawienia, System, Funkcje opcjonalne. Programy leżą potem w C:\Windows\System32\OpenSSH\, a twoja konfiguracja oraz znane host keys w %USERPROFILE%\.ssh\, czyli zazwyczaj w C:\Users\Name\.ssh\known_hosts.

Wersja windowsowa jest opóźniona względem linuksowej. Na aktualnych instalacjach Windows 11 ssh -V zgłasza najczęściej OpenSSH_for_Windows_9.5p2. Do codziennej pracy w zupełności wystarczy.

Jedna osobliwość jednak jest: uprawnienia do plików w Windowsie. Jeśli zapiszesz klucz prywatny, który mogą czytać także inne konta, SSH odmówi współpracy komunikatem Permissions for 'C:\Users\Name\.ssh\id_ed25519' are too open. Naprawisz to tak:

icacls "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r /grant:r "$($env:USERNAME):(R)"

Windows: PuTTY

PuTTY przez lata był standardową drogą pod Windowsem i dla wielu osób nią pozostał. Aktualna jest wersja 0.84 z maja 2026. Pobieraj ją wyłącznie ze strony autora (chiark.greenend.org.uk), a nie z portali z plikami, bo podrobione wersje PuTTY z wbudowaną kradzieżą haseł pojawiały się w przeszłości wielokrotnie.

Przebieg: w polu Host Name (or IP address) wpisujesz adres IP, w Port wartość 22, jako typ połączenia SSH, potem Open. Jeśli chcesz zachować to połączenie, wpisz wcześniej nazwę w Saved Sessions i kliknij Save. O nazwę użytkownika PuTTY pyta dopiero w oknie sesji, możesz ją też zapisać w Connection, Data, Auto-login username.

Przy pierwszym nawiązywaniu połączenia pojawia się okno PuTTY Security Alert z informacją, że host key nie znajduje się w cache'u. Pokazuje ten sam odcisk palca SHA256, który wyświetla też OpenSSH, możesz więc porównać oba jeden do jednego. Accept zapisuje klucz na stałe, Connect Once łączy tylko ten jeden raz bez zapisywania, Cancel przerywa.

Ważna różnica względem OpenSSH: PuTTY nie ma pliku known_hosts. Klucze lądują w rejestrze pod HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys. Kto po ponownej instalacji swojego serwera chce tam posprzątać, otwiera regedit i usuwa właściwy wpis. I jeszcze jedna pułapka: PuTTY używa własnego formatu kluczy (.ppk). Klucz OpenSSH musisz przekonwertować w PuTTYgen przez Conversions, Import key, zanim PuTTY będzie mógł go użyć.

Przesyłanie plików przez scp i sftp

scp kopiuje pliki tak jak cp, tylko przez sieć. Wysłanie pliku na serwer:

scp backup.tar.gz root@203.0.113.10:/root/

Pobranie pliku (kropka na końcu oznacza: do bieżącego katalogu):

scp root@203.0.113.10:/var/log/syslog .

Cały katalog, a także z innym portem:

scp -r website root@203.0.113.10:/var/www/
scp -P 2222 backup.tar.gz root@203.0.113.10:/root/

sftp to wariant interaktywny, wygodny wtedy, gdy najpierw chcesz się rozejrzeć, co gdzie leży:

sftp root@203.0.113.10

Dalej pracujesz poleceniami ls, cd, get plik, put plik po stronie serwera oraz lls, lcd na własnym komputerze. bye kończy sesję. Oba programy są dostępne również pod Windowsem, należą do tej samej instalacji. PuTTY przynosi własne odpowiedniki w postaci pscp i psftp, a kto woli interfejs graficzny, sięga po WinSCP.

A teraz różnica, na której potyka się wiele osób: od OpenSSH 9.0 scp przesyła dane wewnętrznie już nie starym protokołem SCP, tylko przez SFTP. Dotyczy to Debiana 13, Debiana 12 oraz Ubuntu 24.04. Ubuntu 22.04 z OpenSSH 8.9 korzysta jeszcze ze starej metody. W praktyce zauważysz to w dwóch miejscach. Symbole wieloznaczne takie jak *.log w ścieżce zdalnej są interpretowane inaczej, a gdy druga strona nie udostępnia SFTP (na przykład urządzenia sieciowe albo ograniczony chroot), transfer przerywa się komunikatem:

subsystem request failed on channel 0
scp: Connection closed

Rozwiązaniem awaryjnym jest scp -O, które wymusza stary protokół. Czystym rozwiązaniem jest włączenie na serwerze wiersza Subsystem sftp /usr/lib/openssh/sftp-server w /etc/ssh/sshd_config. Na Debianie i Ubuntu potrzebny pakiet openssh-sftp-server instaluje się razem z openssh-server jako jego zależność, brakuje go więc tylko w bardzo nietypowo poskładanych instalacjach.

Ostrzeżenie known_hosts po ponownej instalacji

Instalujesz serwer od nowa, łączysz się i zamiast znaku zachęty pojawia się ściana z wykrzykników:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Offending ED25519 key in /home/tom/.ssh/known_hosts:7
Host key for 203.0.113.10 has changed and you have requested strict checking.
Host key verification failed.

To nie jest usterka, tylko dokładnie ta funkcja, dla której za pierwszym razem wpisałeś yes. Przy ponownej instalacji serwer generuje nowe host keys i stary wpis przestaje pasować. Ten sam komunikat pojawia się zresztą również wtedy, gdy ten sam adres IP trafił do innego klienta albo gdy uruchomiłeś kopię serwera.

Zanim usuniesz wpis, zastanów się przez chwilę: czy naprawdę właśnie instalowałeś system od nowa? Jeśli tak, skasuj stary wiersz:

ssh-keygen -R 203.0.113.10

Przy niestandardowym porcie wpis należy ująć w nawiasy kwadratowe, inaczej polecenie niczego nie znajdzie:

ssh-keygen -R "[203.0.113.10]:2222"

Czy wpis w ogóle istnieje, zdradzi ssh-keygen -F 203.0.113.10. Zaglądanie tam edytorem tekstu zwykle niewiele daje, bo Debian i Ubuntu zapisują nazwy hostów w known_hosts domyślnie jako skrót. Wyszukiwać tam więc nie możesz i stąd te dwa polecenia powyżej.

Przy kolejnej próbie połączenia SSH znów zapyta o odcisk palca. To właśnie ten moment, w którym sprawdzasz go ponownie przez konsolę w panelu klienta, zamiast odruchowo wpisywać yes. Dokładnie ta druga szansa jest sensem całego ostrzeżenia.

Pod Windowsem ssh-keygen -R działa w PowerShellu dokładnie tak samo. Jeśli używasz PuTTY, usuwasz zamiast tego wpis w rejestrze albo potwierdzasz w oknie WARNING - POTENTIAL SECURITY BREACH! przyciskiem Accept, że nowy klucz ma zostać zapisany.

Komunikaty błędów dosłownie i co się za nimi kryje

Poniższe komunikaty pokrywają z doświadczenia zdecydowaną większość wszystkich przypadków.

• Connection refused: połączenie dotarło do serwera, ale na tym porcie nikt nie nasłuchuje. Albo usługa SSH nie działa, albo nasłuchuje na innym porcie. Przez konsolę sprawdzisz poleceniami systemctl status ssh oraz ss -tlnp, czy port 22 jest zajęty.
• Connection timed out: nie przyszła żadna odpowiedź. Typowe przy błędnym adresie IP, wyłączonym serwerze albo firewallu, który pakiety po cichu odrzuca, zamiast jawnie je odbijać. Sprawdź adres IP znak po znaku oraz reguły firewalla.
• Permission denied, please try again.: nazwa użytkownika albo hasło się nie zgadza. Najczęstszą przyczyną jest zły użytkownik, na przykład root zamiast ubuntu albo odwrotnie.
• Permission denied (publickey).: serwer nie przyjmuje haseł w ogóle, tylko klucze. W wielu obrazach chmurowych to ustawienie fabryczne. Albo umieszczasz na serwerze swój klucz publiczny, albo przez konsolę tymczasowo zezwalasz na PasswordAuthentication yes.
• Too many authentication failures: twój agent podaje po kolei zbyt wiele kluczy i serwer przerywa wcześniej. Zaradzisz temu tak: ssh -o IdentitiesOnly=yes -i ~/.ssh/moj_klucz root@203.0.113.10.
• WARNING: UNPROTECTED PRIVATE KEY FILE! razem z Permissions 0644 for ... are too open: klucz prywatny jest czytelny dla innych i dlatego zostaje zignorowany. Pod Linuksem i macOS pomaga chmod 600 na pliku klucza, pod Windowsem polecenie icacls podane wyżej.
• Bad owner or permissions on ~/.ssh/config: ta sama przyczyna, tylko dla pliku konfiguracyjnego. chmod 600 ~/.ssh/config.
• kex_exchange_identification: read: Connection reset by peer: połączenie zostało przerwane w trakcie uzgadniania. W praktyce prawie zawsze chodzi o automatyczną blokadę po kilku nieudanych próbach, na przykład przez fail2ban. Poczekaj do końca blokady albo zdejmij ją przez konsolę poleceniem fail2ban-client unban ADRES_IP.
• no matching host key type found. Their offer: ssh-rsa: serwer oferuje wyłącznie klucze RSA podpisane algorytmem SHA-1. Od OpenSSH 8.8 są one odrzucane, co dotyczy wszystkich czterech omawianych tu systemów w roli klienta. Właściwą odpowiedzią jest aktualizacja starego serwera, a nie osłabianie klienta.
• client_loop: send disconnect: Broken pipe: sesja zasnęła i została sprzątnięta przez firewall albo router. Wpisz w ~/.ssh/config wartość ServerAliveInterval 60, a łącze pozostanie ciepłe.

Zasada podstawowa przy wszelkich pracach nad konfiguracją SSH: zostaw jedną działającą sesję otwartą, kiedy testujesz. Restart usługi SSH nie wyrzuca istniejących połączeń. Jeśli zablokujesz sobie dostęp błędną konfiguracją, wrócisz do środka właśnie przez tę drugą sesję albo przez konsolę w panelu klienta.

Różnice między Debianem 13, Debianem 12, Ubuntu 24.04 i 22.04

Przy samym nawiązywaniu połączenia wszystkie cztery zachowują się tak samo. Gdy tylko zaczniesz coś zmieniać na serwerze, drogi się rozchodzą.

Aktywacja przez socket zamiast usługi działającej stale

Ubuntu od wersji 22.10 nie uruchamia już usługi SSH na stałe, tylko dopiero przy pierwszym połączeniu przychodzącym. Odpowiada za to ssh.socket, a nie ssh.service. Dotyczy to Ubuntu 24.04, a przy świeżo zainstalowanych systemach również Debiana 13. Debian 12 korzysta jeszcze z klasycznej usługi działającej bez przerwy.

Dwie konsekwencje. Po pierwsze, wpis Port 2222 w /etc/ssh/sshd_config nie zmienia tam zupełnie nic, bo na porcie nasłuchuje już nie sshd, tylko systemd. Port trafia wtedy do pliku uzupełniającego, który zakładasz poleceniem systemctl edit ssh.socket, z pustym ListenStream= do skasowania wartości domyślnej i drugim wierszem ListenStream=2222. Po drugie, systemctl reload ssh na świeżo zainstalowanych systemach Debian 13 może przerwać pracę komunikatem fatal: Cannot bind any address. W takim przypadku użyj systemctl restart ssh.service albo wyłącz aktywację przez socket całkowicie poleceniem systemctl disable --now ssh.socket.

Algorytmy i stare zaszłości

Debian 13 przynosi OpenSSH 10.0 i nie zna już kluczy DSA w ogóle, nawet przez przełączniki zgodności. Kto ma jeszcze w użyciu prastary klucz, generuje wcześniej nowy. Bardzo aktualne klienty (macOS 26.3 i nowszy z OpenSSH 10.1 lub wyższym) pokazują dodatkowo komunikat, gdy serwer nie oferuje wymiany kluczy odpornej na komputery kwantowe:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

To ostrzeżenie, a nie błąd, połączenie i tak dochodzi do skutku. Znika, gdy tylko serwer jest wystarczająco nowy. Debian 12 i Ubuntu 24.04 spełniają ten wymóg, Ubuntu 22.04 z OpenSSH 8.9 w konfiguracji domyślnej już nie.

Słowo o starszych wersjach

Debian 10 jest bez wsparcia od czerwca 2024, Ubuntu 20.04 od maja 2025. Żaden z nich nie dostaje już aktualizacji bezpieczeństwa dla OpenSSH. Serwer osiągalny przez SSH z internetu nie powinien już na nich stać.

Mniej pisania dzięki ~/.ssh/config

Gdy tylko opiekujesz się więcej niż jednym serwerem, plik konfiguracyjny się opłaca. Załóż go i ustaw uprawnienia, inaczej SSH go odrzuci:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

Wpis w nim wygląda tak:

Host web1
    HostName 203.0.113.10
    User root
    Port 2222
    ServerAliveInterval 60

Potem wystarczy ssh web1, a scp plik web1:/root/ również zadziała w ten sposób. Ten sam plik rozumie klient windowsowy, leży tam pod %USERPROFILE%\.ssh\config.

Nie musisz zgadywać, czy twój blok naprawdę działa. ssh -G pokazuje ostateczną konfigurację, nie nawiązując przy tym połączenia:

ssh -G localhost

Zastąp localhost swoją nazwą skróconą, a w wierszach hostname, user oraz port zobaczysz czarno na białym, czego SSH zaraz użyje. Literówka w nazwie po Host rzuca się wtedy w oczy po dwóch sekundach, a nie po dwudziestu minutach szukania błędu.

Po czym poznasz, że naprawdę się udało

Sam znak zachęty, który się pojawia, jeszcze niczego nie dowodzi. Przy kilku otwartych oknach niejedna osoba wykonała już rm na niewłaściwym serwerze. Cztery krótkie polecenia dają jasność:

hostname
id
cat /etc/os-release
uptime

hostname musi pokazać nazwę twojego serwera, a nie twojego laptopa. id pokazuje uid=0(root), gdy pracujesz jako root. cat /etc/os-release podaje dystrybucję i wersję, czyli na przykład Debian GNU/Linux 13 (trixie) albo Ubuntu 24.04.3 LTS. A uptime pasuje do czasu pracy serwera, a nie komputera biurowego, który co wieczór jest wyłączany.

Najszybszy test na to, czy siedzisz naprawdę na SSH, a nie w lokalnym terminalu:

echo $SSH_CONNECTION

Jeśli pojawi się wiersz z czterema wartościami (twój adres IP, twój port źródłowy, adres IP serwera, port docelowy), jesteś zalogowany. Jeśli pozostanie pusty, piszesz właśnie na własnym komputerze. Sesję kończysz poleceniem exit albo skrótem klawiszowym Ctrl i D.

Co dalej

Kolejnym sensownym krokiem jest przejście z haseł na klucze. Klucza SSH nie da się zgadnąć, a potem możesz całkowicie wyłączyć logowanie hasłem, przez co większość automatycznych prób ataku trafia w próżnię. Jak to zrobić, opisuje konfiguracja uwierzytelniania kluczem SSH. Dalej przychodzi kolej na firewall i automatyczne blokowanie, opisane w tekście zabezpieczanie serwera po instalacji.

Na początek obowiązuje jedno: kiedy już raz jesteś w środku, sprawdziłeś odcisk palca i wiesz, jak wrócić do systemu po ponownej instalacji, najtrudniejsza część jest za tobą. Wszystko inne dzieje się już w oknie, które możesz teraz otworzyć.