SSH: jak połączyć się z serwerem, klucze i najczęstsze błędy

Praca na serwerze, wdrażanie aplikacji i git push na GitHuba mają wspólny mianownik: SSH. W tym artykule wyjaśniam, czym jest SSH, jak się połączyć, czym są klucze prywatne i publiczne, jak użyć ich z GitHubem, jakich klientów używać na Windowsie, macOS i Linuxie i jakie błędy zdarzają się najczęściej. Na końcu opisuję świeżą podatność w OpenSSH, która dobrze pokazuje, dlaczego hasła na serwerze są ryzykiem. Komendy ssh-keygen, uprawnienia plików i konfigurację sprawdziłem lokalnie na macOS, a logowania do prawdziwego serwera i do GitHuba nie testowałem, więc te fragmenty opieram na oficjalnej dokumentacji.

Jeśli dopiero zaczynasz pracę w terminalu, zobacz wcześniej artykuł o terminalu i wierszu poleceń, a o samych serwerach przeczytasz w tekście o serwerze VPS.

Czym jest SSH i do czego służy?

SSH (Secure Shell) to protokół zdalnego logowania, który szyfruje cały ruch między Twoim komputerem (klientem) a serwerem. Według dokumentacji Microsoft szyfrowanie chroni przed podsłuchem i przejęciem połączenia. Najczęściej używa się go do:

• pracy w terminalu zdalnego serwera, np. VPS,
• wdrażania aplikacji i zarządzania serwerem,
• połączeń z GitHubem i innymi repozytoriami Gita,
• bezpiecznego przesyłania plików (protokół SFTP działa przez SSH).

Serwer SSH domyślnie nasłuchuje na porcie 22. Najpopularniejszą implementacją jest OpenSSH, która w tym artykule jest punktem odniesienia.

Jak połączyć się z serwerem przez SSH?

Podstawowe polecenie wygląda tak:

ssh ania@203.0.113.10

ania to nazwa użytkownika na serwerze, a 203.0.113.10 to jego adres IP (może to być też nazwa domenowa). Przy pierwszym połączeniu klient pokaże komunikat o odcisku klucza serwera (host key fingerprint) i zapyta, czy chcesz kontynuować. Dokumentacja Microsoft opisuje to tak: wpisanie yes dodaje serwer do listy znanych hostów na Twoim komputerze. Dobra praktyka to porównać odcisk z tym, który podaje dostawca serwera, zamiast wpisywać yes na ślepo, bo to chroni przed podszyciem się pod serwer.

Potem serwer poprosi o hasło (znaki nie są wyświetlane) albo, jeśli masz skonfigurowane klucze, wpuści Cię bez hasła.

Czym są klucz prywatny i klucz publiczny?

Zamiast hasła SSH może używać pary kluczy, która działa jak zamek i klucz:

Serwer, który ma Twój klucz publiczny, wpuści tylko kogoś, kto udowodni, że posiada pasujący klucz prywatny, a sam klucz prywatny nigdy nie jest wysyłany przez sieć. Dlatego jest bezpieczniejszy niż hasło: nie da się go zgadnąć ani przejąć podsłuchem połączenia. Najważniejsza zasada: klucza prywatnego nie wysyła się nikomu, nie wkleja do czatu i nie dodaje do repozytorium.

Uwaga mentora: klucz prywatny traktuj jak hasło do wszystkiego: nie wysyłaj go przez komunikator, nie wrzucaj do repozytorium i zabezpiecz go hasłem. Zgubiony lub wyciekły klucz wymieniasz, a nie „ukrywasz”.

Jak wygenerować klucz SSH?

Według dokumentacji GitHub zalecanym algorytmem jest Ed25519. Polecenie wygląda tak:

ssh-keygen -t ed25519 -C "twoj@adres.pl"

Program zapyta, gdzie zapisać klucz (domyślnie ~/.ssh/id_ed25519) i o hasło do klucza (passphrase). Hasło do klucza warto ustawić: jeśli ktoś ukradnie plik klucza, nadal będzie potrzebował tej frazy. Na starszych systemach bez Ed25519 dokumentacja GitHub podaje wariant ssh-keygen -t rsa -b 4096.

Sprawdziłem to polecenie lokalnie (w katalogu tymczasowym, nie w ~/.ssh). Wynik:

• powstały dwa pliki: prywatny z uprawnieniami -rw------- (tylko właściciel) i publiczny -rw-r--r-- (do odczytu przez innych),
• plik prywatny zaczyna się od -----BEGIN OPENSSH PRIVATE KEY-----, a publiczny od ssh-ed25519 AAAA… i na końcu ma komentarz z Twoim adresem,
• ssh-keygen -lf plik.pub wypisuje odcisk w postaci 256 SHA256:… twoj@adres.pl (ED25519).

Hasło do istniejącego klucza zmienisz poleceniem ssh-keygen -p -f ~/.ssh/id_ed25519 (komunikat po sukcesie: „Your identification has been saved with the new passphrase.”).

Jak dodać klucz publiczny na serwerze?

Klucz publiczny trafia do pliku ~/.ssh/authorized_keys na serwerze, w katalogu użytkownika, do którego chcesz się logować. Najprościej zrobić to poleceniem ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub ania@203.0.113.10

Polecenie logujesz hasłem jeszcze ten jeden raz, a potem logowanie działa już na klucz. Tego polecenia nie testowałem na prawdziwym serwerze. Zanim wyłączysz hasła, sprawdź w drugim oknie terminala, że logowanie kluczem działa. Inaczej możesz zamknąć sobie dostęp do własnego serwera. Szczegóły, jak wyłączyć hasła w konfiguracji sshd, są w artykule o serwerze VPS.

Jak użyć klucza SSH na GitHubie?

Z GitHubem klucz służy do git clone, git pull i git push bez wpisywania hasła przy każdym razie. Kroki według dokumentacji GitHub:

1. Wygeneruj klucz (powyżej).
2. Dodaj klucz do agenta SSH, żeby nie wpisywać hasła do klucza za każdym razem. Na Linuxie: eval "$(ssh-agent -s)", a potem ssh-add ~/.ssh/id_ed25519. Na macOS dokumentacja podaje ssh-add --apple-use-keychain ~/.ssh/id_ed25519, które zapisuje hasło do klucza w pęku kluczy.
3. Dodaj klucz publiczny do konta GitHub w ustawieniach (sekcja „SSH and GPG keys”). Wklejasz zawartość pliku .pub, a nie prywatnego!
4. Sprawdź połączenie:

ssh -T git@github.com

Przy pierwszym połączeniu zobaczysz pytanie o odcisk klucza serwera GitHuba (dokumentacja podaje odcisk ED25519 do porównania). Po sukcesie komunikat brzmi: „Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access.” Połączenie zawsze idzie na użytkownika git, a nie na Twoją nazwę na GitHubie. Podstawy pracy z repozytoriami znajdziesz w artykule o Git i GitHub: clone, fork i pull request.

Jak ułatwić sobie pracę plikiem ~/.ssh/config i ssh-agentem?

Zamiast za każdym razem wpisywać adres, użytkownika i klucz, zapisz je w pliku ~/.ssh/config:

Host moj-serwer
  HostName 203.0.113.10
  User ania
  Port 22
  IdentityFile ~/.ssh/id_ed25519

Od tej pory wystarczy ssh moj-serwer. Sprawdziłem lokalnie, że ssh -F plik -G moj-serwer rozwiązuje alias na użytkownika ania, host 203.0.113.10, port 22 i wskazany klucz. Dla GitHuba dokumentacja podaje dla macOS wpis z AddKeysToAgent yes, UseKeychain yes i IdentityFile ~/.ssh/id_ed25519 (jeśli pojawi się błąd o opcji usekeychain, dodaj IgnoreUnknown UseKeychain).

Agent SSH (ssh-agent) trzyma odblokowany klucz w pamięci, więc hasło do klucza wpisujesz raz na sesję.

Jakich klientów SSH używać na Windowsie, macOS i Linuxie?

Polecenie na Windowsie wygląda tak samo jak na macOS i Linuxie, np. ssh ania@203.0.113.10. Dokumentacja Microsoft zaznacza, że klienta zainstalowanego przez Optional Features aktualizuje Windows Update. Jeśli używasz WSL, ten sam ssh działa wewnątrz systemu Linux, a klucze są osobne od tych w Windowsie.

Jakie błędy SSH zdarzają się najczęściej?

Pierwszym narzędziem diagnostycznym jest tryb szczegółowy: ssh -v ania@203.0.113.10 (dla GitHuba ssh -vT git@github.com). Pokazuje, jakie klucze klient próbuje i gdzie połączenie się zatrzymuje. Dokumentacja GitHub podaje też wariant ssh -i ~/.ssh/KEY-FILE -vT git@github.com dla klucza o niestandardowej nazwie.

Dlaczego na serwerze lepiej wyłączyć hasła? Podatność „SSHole” w OpenSSH

W listopadzie 2026 poprawiono błąd w OpenSSH, który bardzo dobrze pokazuje ryzyko haseł. Wydanie OpenSSH 10.6p2 z 5 listopada 2026 usuwa „password authentication bypass”, czyli możliwość ominięcia uwierzytelniania hasłem, na systemach Linux z biblioteką musl libc i wyłączonym PAM. Błąd dostał oznaczenie CVE-2026-123158 (przezwisko „SSHole”) i ocenę 8,1 w skali CVSS (poziom wysoki). Według rekordu CVE na części kont akceptowane było dowolne hasło o długości 256–1024 znaków (źródła różnią się o jeden znak lub bajt).

Z doniesień prasy (SecurityWeek) wynika, że atak dotyczy kont z hasłem ustawionym na *, czyli takich, które miały logować się tylko kluczem (np. root), i wymaga, żeby w systemie było też inne konto z hashem hasła i żeby atakujący znał nazwę konta. Dotyczy to dystrybucji opartych na musl, takich jak Alpine Linux, OpenWrt, Buildroot i Yocto. Dystrybucje typu Debian, Ubuntu i RHEL zwykle używają innej biblioteki i PAM, więc nie pasują do tych warunków, ale źródła nie potwierdzają tego wprost. Sprawdź komunikat bezpieczeństwa swojej dystrybucji. Rekord CVE wskazuje, że luka znalazła się 9 listopada 2026 w katalogu aktywnie wykorzystywanych podatności amerykańskiej agencji CISA, a status wykorzystania oznaczono jako aktywny.

Co z tego wynika dla Ciebie:

• Zaktualizuj OpenSSH do wersji 10.6p2 lub do poprawki swojej dystrybucji.
• Wyłącz logowanie hasłem (PasswordAuthentication no w sshd_config) i używaj kluczy. To obejście podają źródła, gdy aktualizacja nie jest możliwa od razu.
• Nie zostawiaj kont z hasłami, których nie potrzebujesz.

Ten błąd dotyczy konkretnej konfiguracji, ale lekcja jest ogólna: hasło można zgadnąć albo ominąć błędem, a klucza prywatnego nie ma jak podsłuchać w sieci. Stan wiedzy o podatności jest z 10 listopada 2026, więc przed wdrożeniem sprawdź aktualne komunikaty.

Jak bezpiecznie korzystać z SSH? Krótka lista

1. Używaj kluczy Ed25519 z hasłem do klucza i trzymaj prywatny klucz tylko u siebie.
2. Wyłącz logowanie hasłem i logowanie roota po sprawdzeniu, że klucz działa.
3. Aktualizuj system i OpenSSH.
4. Ogranicz dostęp zaporą (osobny artykuł o zaporze będzie w tym cyklu).
5. Nie ignoruj ostrzeżeń o zmianie klucza serwera.
6. Rób kopię zapasową klucza prywatnego w bezpiecznym miejscu, bo bez niego stracisz dostęp.

Jak sprawdzić SSH w praktyce? Ćwiczenie na 10 minut

Najszybciej zrozumiesz SSH, gdy przejdziesz cały obieg z GitHubem. To moja propozycja ćwiczenia, a nie oficjalny kurs:

1. Wygeneruj klucz: ssh-keygen -t ed25519 -C "twoj@adres.pl" i ustaw hasło do klucza.
2. Dodaj klucz do agenta: ssh-add ~/.ssh/id_ed25519 (na macOS według dokumentacji GitHub z opcją --apple-use-keychain).
3. Wklej zawartość pliku id_ed25519.pub do ustawień konta GitHub w sekcji „SSH and GPG keys”. Wklejasz plik z końcówką .pub, nigdy plik bez niej.
4. Sprawdź połączenie: ssh -T git@github.com. Przy pierwszym połączeniu porównaj odcisk z podanym w dokumentacji GitHub, a po sukcesie zobaczysz komunikat „Hi USERNAME! You've successfully authenticated…”.
5. Sklonuj dowolne swoje repozytorium przez SSH. Adres w formie SSH znajdziesz na stronie repozytorium w zakładce z przyciskiem klonowania.
6. Zepsuj coś celowo i napraw: zmień uprawnienia pliku klucza na 644, zobacz komunikat „UNPROTECTED PRIVATE KEY FILE”, i przywróć 600.

Jeśli któryś krok nie działa, wróć do tabeli błędów powyżej i uruchom polecenie z opcją -v.

Co dalej po SSH?

Z SSH korzystają też scp i SFTP do przesyłania plików oraz tunelowanie, które pozwala bezpiecznie przekierować port, np. do bazy danych. To tematy na osobne artykuły. Jeśli chcesz zobaczyć cały proces wdrożenia na prawdziwym serwerze, zajrzyj do modułu wdrożenie produkcyjne w chmurze w kursie AI Engineer.

Podsumowanie

• SSH szyfruje połączenie z serwerem i służy do pracy w terminalu, wdrożeń i połączeń z GitHubem.
• Para kluczy (publiczny na serwerze lub GitHubie, prywatny tylko u Ciebie) jest bezpieczniejsza niż hasło. Klucz generujesz poleceniem ssh-keygen -t ed25519.
• Pliki klucza prywatnego muszą mieć uprawnienia 600. Przy zbyt szerokich klient ignoruje klucz i pisze „UNPROTECTED PRIVATE KEY FILE”.
• Częste błędy: Permission denied (publickey), Connection refused i zbyt szerokie uprawnienia klucza.
• Podatność CVE-2026-123158 (poprawka w OpenSSH 10.6p2 z 5 listopada 2026) dotyczy Linuxa z musl bez PAM i pokazuje, że warto wyłączyć hasła i używać kluczy.
• Komendy z kluczami i konfiguracją sprawdziłem na macOS, a logowania do prawdziwego serwera i do GitHuba opisałem na podstawie dokumentacji.