SSH dla początkujących: bezpieczne łączenie się z serwerem krok po kroku

Cel korzystania z SSH i oczekiwany efekt

Osoba zaczynająca pracę z serwerem przez SSH chce osiągnąć dwie rzeczy: zrozumieć, co dokładnie robi SSH oraz umieć bezpiecznie zalogować się do zdalnego serwera – najlepiej z kluczami, bez wpisywania hasła przy każdym połączeniu. Dodatkowo celem jest uniknięcie typowych pułapek, które mogą unieruchomić serwer lub narazić go na ataki.

Frazy pomocnicze: co to jest ssh, pierwsze logowanie ssh, konfiguracja ssh w windows, klucze ssh krok po kroku, ssh a bezpieczeństwo, ssh bez hasła, konfiguracja pliku sshd_config, typowe błędy ssh, ssh przez putty, ssh na mac i linux, ochronia serwera ssh, praktyczne komendy ssh

Czym jest SSH i po co go używać

Krótka historia i kontekst (Telnet vs SSH)

SSH (Secure Shell) to protokół do bezpiecznego zdalnego logowania i wykonywania poleceń na innym komputerze. Powstał jako odpowiedź na problemy z Telnetem i podobnymi narzędziami, które przesyłały dane jawnie – bez jakiegokolwiek szyfrowania.

W czasach Telnetu administrator logował się do serwera komendą w stylu telnet serwer.example.com, a następnie wpisywał login i hasło. Cała ta komunikacja wędrowała przez sieć w postaci czystego tekstu. Każdy, kto potrafił podsłuchać ruch w sieci (np. na tym samym Wi-Fi), mógł:

• podejrzeć nazwę użytkownika i hasło,
• zobaczyć wszystkie wpisywane komendy,
• przeczytać cały tekst wyświetlany przez serwer (np. zawartość edytowanych plików).

SSH rozwiązuje ten problem, wprowadzając szyfrowane połączenie między klientem a serwerem. Zamiast czystego tekstu, po sieci krążą zaszyfrowane pakiety, których podsłuchujący nie może zrozumieć bez odpowiedniego klucza.

Co dokładnie szyfruje SSH

SSH szyfruje całą sesję komunikacji: od chwili nawiązania połączenia, przez proces logowania, aż po wszystkie komendy i odpowiedzi serwera. Obejmuje to m.in.:

• login i hasło (jeśli korzystasz z logowania hasłem),
• klucze sesyjne i dane uwierzytelniające,
• wszystkie wpisywane komendy,
• wszystkie dane zwracane przez serwer (wyniki poleceń, logi, treść plików),
• tunelowane połączenia (forwardowane porty, np. gdy przekierowujesz ruch HTTP przez SSH).

Bez SSH ruch wygląda jak czytelny tekst. Z SSH w podsłuchu zobaczysz jedynie pakiety, których zawartość jest nieczytelna, chyba że posiadasz klucze wykorzystywane w sesji. Dla podsłuchującego użycie SSH oznacza utratę możliwości podglądu i modyfikacji treści komunikacji (o ile nie jest w stanie przeprowadzić bardziej złożonego ataku typu man-in-the-middle – o tym chroni m.in. weryfikacja klucza hosta).

SSH jako protokół do logowania i tunelowania

SSH kojarzy się głównie z logowaniem do serwerów, ale jego możliwości są szersze. Dwa najważniejsze zastosowania:

• Zdalne logowanie – klasyczny przypadek: łączysz się do serwera VPS, maszyny w chmurze czy fizycznego serwera, aby:
  • zarządzać systemem (instalować pakiety, konfigurować usługi),
  • edytować pliki konfiguracyjne,
  • monitorować zużycie zasobów, logi i procesy.
• Tunelowanie (port forwarding) – SSH potrafi przenosić inny ruch sieciowy w swoim zaszyfrowanym tunelu. Typowe przykłady:
  • przekierowanie portu bazy danych z serwera na lokalny komputer,
  • bezpieczne połączenie do wewnętrznego panelu administracyjnego poprzez tunel SSH zamiast wystawiania go publicznie.

Dodatkowo SSH jest używane pośrednio przez inne narzędzia, np. Git może korzystać z SSH do uwierzytelniania (klucz publiczny powiązany z kontem w systemie Git), co eliminuje konieczność wpisywania loginu i hasła przy każdym git push.

Klient SSH i serwer SSH (ssh vs sshd)

Architektura SSH jest prosta:

• Klient SSH – program uruchamiany na twoim komputerze (np. ssh w terminalu), który inicjuje połączenie.
• Serwer SSH (sshd) – usługa działająca na zdalnej maszynie, nasłuchująca na określonym porcie (domyślnie 22) i przyjmująca połączenia.

Kiedy wykonasz np. ssh user@1.2.3.4, twój klient SSH:

1. nawiązuje połączenie TCP z serwerem SSH na porcie 22 (lub innym, jeśli podasz),
2. uzgadnia algorytmy szyfrowania i generuje klucz sesyjny,
3. weryfikuje klucz hosta (fingerprint serwera),
4. przeprowadza proces uwierzytelnienia (hasło lub klucz),
5. po pomyślnym logowaniu udostępnia interaktywną powłokę (shell) lub wykonuje jedno konkretne polecenie.

Podstawowe pojęcia: klucz publiczny, prywatny, host, port, użytkownik

Adres hosta, nazwa użytkownika i port w połączeniu SSH

Typowe polecenie łączenia przez SSH wygląda tak:

ssh user@host -p 22

Każdy element ma swoje znaczenie:

• user – nazwa użytkownika w systemie na serwerze (np. root, deploy, ubuntu),
• host – adres serwera:
  • adres IP (np. 192.0.2.10),
  • nazwa domenowa (np. serwer.example.com),
  • czasem nietypowy port zakodowany w konfiguracji, ale to już inny mechanizm.
• -p 22 – numer portu TCP, na którym nasłuchuje serwer SSH; domyślnie 22, ale wielu administratorów zmienia go na inny (np. 2222, 22022) dla ograniczenia skanów automatycznych.

Jeśli nie podasz -p, klient SSH przyjmie port 22. W praktyce często dostawca hostingu podaje konkretny port, np. Port SSH: 2222. Wówczas polecenie przybierze postać:

ssh user@1.2.3.4 -p 2222

Model klucza publicznego (asymetryczne szyfrowanie)

SSH opiera się na kryptografii asymetrycznej. W skrócie: używa się pary kluczy:

• klucz prywatny – trzymany tylko u ciebie, nie wolno go nikomu wysyłać ani upubliczniać,
• klucz publiczny – można go dowolnie kopiować i umieszczać na serwerach, do których chcesz mieć dostęp.

Praktyczna analogia: klucz publiczny to kłódka, którą możesz wysyłać wszystkim, a klucz prywatny to jedyny klucz otwierający tę kłódkę. Serwer przechowuje twoją „kłódkę” (klucz publiczny), a gdy próbujesz się zalogować:

1. serwer sprawdza, czy masz odpowiedni klucz prywatny,
2. wysyła wyzwanie zaszyfrowane kluczem publicznym,
3. twój klient odsyła poprawną odpowiedź tylko wtedy, gdy posiada pasujący klucz prywatny.

Cała ta wymiana odbywa się tak, że klucz prywatny nigdy nie opuszcza twojego komputera. Dzięki temu nawet jeśli ktoś podsłuchuje ruch, nie „przechwyci” klucza prywatnego w trakcie logowania.

Fingerprint serwera (odcisk klucza hosta)

Przy pierwszym połączeniu z nowym serwerem kreator SSH wyświetla komunikat w stylu:

The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established.
ECDSA key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

To tzw. fingerprint, czyli skrót klucza hosta (klucza publicznego serwera). Zadaniem użytkownika jest sprawdzić, czy ten odcisk zgadza się z tym, który podał dostawca serwera (np. w panelu hostingu). Jeśli się zgadza, wpisujesz yes, a klient zapisuje ten fingerprint w pliku ~/.ssh/known_hosts.

Od tego momentu przy każdym kolejnym połączeniu klient weryfikuje, czy klucz hosta się nie zmienił. Jeśli się zmieni – zobaczysz ostrzeżenie o możliwym ataku typu man-in-the-middle lub o tym, że ktoś przeinstalował serwer (lub zmienił jego klucz bez poinformowania).

Logowanie hasłem vs logowanie kluczem

SSH obsługuje dwa główne typy uwierzytelniania użytkownika:

• Hasło – połączenie szyfrowane, ale czynnik uwierzytelniający to zwykłe hasło:
  • łatwiejsze na start,
  • bardziej podatne na ataki słownikowe / brute force,
  • wymaga wpisywania hasła przy każdym logowaniu (chyba że dołoży się inne mechanizmy).
• Klucz SSH – uwierzytelnianie na podstawie pary kluczy:
  • brak wpisywania hasła przy każdym połączeniu (lub tylko passphrase do klucza),
  • znacznie wyższe bezpieczeństwo, jeśli klucz prywatny jest dobrze chroniony,
  • możliwość wyłączenia logowania hasłem na serwerze (mocne ograniczenie ataków).

W praktyce popularny scenariusz wygląda tak: pierwsze logowanie odbywa się hasłem, potem generowany jest klucz SSH i instalowany na serwerze, a na końcu logowanie hasłem jest wyłączane, pozostawiając jedynie logowanie kluczami.

Gdzie są trzymane klucze i pliki konfiguracyjne SSH

Na większości systemów (Linux/macOS/Windows z OpenSSH) klucze i konfiguracja użytkownika znajdują się w katalogu ~/.ssh (czyli w twoim katalogu domowym). Najważniejsze pliki:

• ~/.ssh/id_rsa, ~/.ssh/id_ed25519 – klucze prywatne (nie udostępniać!),
• ~/.ssh/id_rsa.pub, ~/.ssh/id_ed25519.pub – odpowiadające im klucze publiczne,
• ~/.ssh/authorized_keys – na serwerze: lista kluczy publicznych, które mogą się logować jako dany użytkownik,
• ~/.ssh/known_hosts – lista poznanych kluczy hosta serwerów; klient używa jej do weryfikacji, czy serwer się nie „podmienił”,
• ~/.ssh/config – opcjonalny plik konfiguracyjny klienta, gdzie można definiować aliasy hostów, domyślne porty itd.

Na serwerze globalna konfiguracja demona SSH (sshd) zazwyczaj znajduje się w /etc/ssh/sshd_config. Modyfikacje w tym pliku wpływają na to, jak serwer przyjmuje połączenia i jakie metody uwierzytelniania akceptuje.

Przygotowanie środowiska: narzędzia SSH na Windows, macOS i Linux

Wbudowany klient SSH vs PuTTY i inne narzędzia

Do łączenia się z serwerem przez SSH potrzebny jest klient SSH. Obecnie większość systemów ma go wbudowanego, ale w świecie Windows wciąż funkcjonuje PuTTY, który przez długie lata był standardem.

SSH na Linux i macOS

Na Linuksie i macOS klient SSH (ssh) jest praktycznie zawsze zainstalowany domyślnie. Aby sprawdzić wersję, wystarczy w terminalu wykonać:

ssh -V

Przykładowy wynik:

OpenSSH_9.3p1, LibreSSL 3.3.6

Jeśli system zwróci informację, że komenda nie istnieje, można doinstalować pakiet. Na Linuksie zależy to od dystrybucji, np.:

• Debian/Ubuntu: sudo apt install openssh-client,
• Fedora/CentOS/RHEL: sudo dnf install openssh-clients lub sudo yum install openssh-clients.

SSH na Windows 10/11 – wbudowany OpenSSH

Nowsze wersje Windows (10 i 11) zawierają wbudowanego klienta OpenSSH. Aby sprawdzić, czy jest dostępny, włącz PowerShell lub cmd i wpisz:

ssh -V

Jeśli zobaczysz wersję, możesz od razu korzystać z komendy ssh tak samo jak na Linuksie. Jeśli system mówi, że polecenie nie jest rozpoznawane, trzeba włączyć funkcję „OpenSSH Client”:

Włączenie i konfiguracja klienta OpenSSH w Windows

W systemach Windows 10/11 klient OpenSSH jest funkcją opcjonalną. Jeśli polecenie ssh nie działa, trzeba je doinstalować:

1. Otwórz Ustawienia > Aplikacje > Funkcje opcjonalne.
2. Sprawdź, czy na liście jest OpenSSH Client. Jeśli tak – powinien być już zainstalowany.
3. Jeśli go nie ma, kliknij Dodaj funkcję i wyszukaj OpenSSH Client, następnie zainstaluj.

Po instalacji zamknij i ponownie uruchom PowerShell/cmd. Polecenie ssh -V powinno zwrócić wersję klienta OpenSSH.

Tip: wygodnie jest używać PowerShell zamiast starego cmd – obsługuje lepiej UTF-8 i aliasy.

PuTTY – kiedy nadal ma sens

PuTTY to wciąż popularny klient w środowiskach, gdzie użytkownicy nie korzystają z terminala na co dzień. Przydaje się zwłaszcza, gdy:

• ktoś woli interfejs graficzny do zarządzania sesjami,
• potrzebne jest szybkie przeklikiwanie się między wieloma serwerami,
• pracujesz na starszym Windowsie bez wbudowanego OpenSSH.

Aby używać PuTTY z kluczami SSH, potrzebny będzie dodatkowo program PuTTYgen (generator kluczy) oraz opcjonalnie Pageant (agent kluczy). Model działania jest taki sam jak w OpenSSH, różni się tylko sposób konfiguracji.

Inne przydatne narzędzia: menedżery terminala i agenty kluczy

Przy pracy z wieloma serwerami pojawia się temat wygody. Zamiast wielu osobnych okien terminala można wykorzystać nowoczesne narzędzia:

• Windows Terminal – obsługuje karty, profile dla PowerShell/cmd/WLS, działa dobrze z OpenSSH,
• tmux (Linux/macOS) – multiplexer terminala, pozwala dzielić okno i utrzymywać sesje nawet po rozłączeniu,
• ssh-agent / gpg-agent – trzymają klucze w pamięci, żeby nie wpisywać passphrase przy każdym połączeniu.

Podstawowy agent w systemach z OpenSSH można uruchomić tak:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Po podaniu passphrase agent będzie obsługiwał logowania bez ponownego wpisywania hasła do klucza w danej sesji.

Pierwsze połączenie SSH krok po kroku

Informacje potrzebne przed pierwszym logowaniem

Żeby połączyć się z serwerem, trzeba mieć kilka podstawowych danych. Zazwyczaj dostarcza je administrator lub panel hostingu:

• adres serwera (IP lub domena, np. 203.0.113.12 lub serwer.example.com),
• użytkownik (np. root, ubuntu, deploy),
• port SSH (domyślnie 22, czasem np. 2222),
• metoda logowania – hasło lub klucz SSH,
• opcjonalnie fingerprint klucza hosta – dobry dostawca go publikuje.

Łączenie z Linux/macOS – przykład krok po kroku

Załóżmy, że masz dane:

• adres: 203.0.113.12,
• użytkownik: ubuntu,
• port: 22,
• logowanie: hasło.

W terminalu wpisujesz:

ssh ubuntu@203.0.113.12

1. Przy pierwszym połączeniu zobaczysz komunikat z fingerprintem hosta, o którym była mowa wcześniej.
2. Po wpisaniu yes klient zapisze serwer w ~/.ssh/known_hosts.
3. Następnie pojawi się prośba o podanie hasła:

   ubuntu@203.0.113.12's password:
   

4. Po poprawnym uwierzytelnieniu znajdziesz się w powłoce na serwerze, co widać po zmianie zachęty (promptu), np.:

   ubuntu@serwer:~$
   

Łączenie z Windows (PowerShell) – przykład

W PowerShell mechanika jest identyczna. Dla hosta z niestandardowym portem:

• adres: serwer.example.com,
• użytkownik: deploy,
• port: 2222.

W PowerShell wpisujesz:

ssh deploy@serwer.example.com -p 2222

Dalej przebieg jest taki sam jak na Linuksie: akceptacja fingerprintu, podanie hasła, otrzymanie powłoki.

Test połączenia i podstawowe komendy po zalogowaniu

Po zalogowaniu warto wykonać kilka prostych komend, aby upewnić się, że sesja działa poprawnie i zorientować się w środowisku:

• whoami – pokazuje aktualnego użytkownika,
• hostname – nazwa serwera,
• pwd – aktualny katalog (powinien to być katalog domowy użytkownika),
• ls – lista plików w katalogu.

Typowy scenariusz pierwszego połączenia do świeżego VPS-a: logujesz się jako dostarczony użytkownik (często root lub ubuntu), tworzysz własnego użytkownika nie-root, generujesz klucze, konfigurować SSH i wyłączasz logowanie hasłem.

Rozłączanie się z serwerem SSH

Sesję SSH można zakończyć na kilka sposobów:

• najprościej: polecenie exit lub skrót Ctrl+D,
• w nagłych sytuacjach: zamknięcie okna terminala.

Istnieje też „escape sequence” klienta SSH (domyślnie ~. wpisane na początku nowej linii), która twardo rozłącza sesję, gdy np. zawiśnie zdalny shell.

Klucze SSH w praktyce: generowanie, instalacja, używanie

Wybór typu klucza: RSA vs ED25519

Obecnie dobrym wyborem dla większości użytkowników jest ED25519 – algorytm nowocześniejszy, z krótszymi kluczami i szybszy niż klasyczne RSA. RSA wciąż jest szeroko wspierane, ale nowe instalacje można spokojnie opierać na ED25519, jeśli nie ma specyficznych wymagań kompatybilności.

Podsumowanie praktyczne:

• jeśli nie wiesz, co wybrać – użyj ED25519,
• jeśli masz bardzo stary sprzęt/oprogramowanie – czasem pozostaje RSA.

Generowanie kluczy SSH na Linux/macOS/Windows (OpenSSH)

Standardowe polecenie do generowania klucza ED25519:

ssh-keygen -t ed25519 -C "opis-klucza"

Znaczenie parametrów:

• -t ed25519 – typ klucza,
• -C "opis-klucza" – komentarz, np. e-mail lub nazwa maszyny, ułatwia identyfikację klucza na serwerze.

Przykładowy przebieg:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):

Można zatwierdzić ścieżkę domyślną (Enter). Następnie:

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Passphrase to hasło chroniące klucz prywatny. Dobrze je ustawić, szczególnie na laptopach. Jeśli zostawisz puste, klucz nie będzie dodatkowo zabezpieczony – wygodniejsze, ale mniej bezpieczne.

Po zakończeniu w katalogu ~/.ssh pojawią się:

• id_ed25519 – klucz prywatny,
• id_ed25519.pub – klucz publiczny.

Generowanie klucza SSH w PuTTYgen (Windows)

Jeśli pracujesz z PuTTY:

1. Uruchom PuTTYgen.
2. Wybierz typ klucza: Ed25519 (lub RSA, jeśli musisz),
3. Kliknij Generate i poruszaj myszą w oknie, aż pasek postępu się wypełni (zbieranie entropii),
4. Ustal Key passphrase i Confirm passphrase,
5. Kliknij Save private key, aby zapisać klucz prywatny (.ppk),
6. Skopiuj zawartość pola Public key for pasting into OpenSSH authorized_keys file – to odpowiednik pliku .pub.

PuTTY używa własnego formatu pliku klucza prywatnego (.ppk), ale klucz publiczny jest kompatybilny z OpenSSH i można go wklejać do authorized_keys.

Instalacja klucza publicznego na serwerze

Instalacja klucza polega na dopisaniu go do pliku ~/.ssh/authorized_keys wybranego użytkownika na serwerze. Sposoby są różne w zależności od dostępu.

Automatyczna instalacja: ssh-copy-id

Na wielu systemach (głównie Linux) dostępne jest narzędzie ssh-copy-id. Uproszcza ono proces:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

Mechanizm:

1. łączenie na podstawie hasła,
2. utworzenie katalogu ~/.ssh na serwerze (jeśli nie istnieje),
3. dodanie zawartości twojego .pub do ~/.ssh/authorized_keys.

Ręczna instalacja klucza przez kopiowanie

Jeśli ssh-copy-id nie jest dostępny lub wolisz mieć pełną kontrolę, można to zrobić ręcznie:

1. Wyświetl zawartość klucza publicznego na lokalnej maszynie:

   cat ~/.ssh/id_ed25519.pub
   

2. Skopiuj całą linię (od ssh-ed25519 do końca komentarza).
3. Zaloguj się na serwer hasłem.
4. Utwórz katalog ~/.ssh (jeśli go nie ma) i ustaw poprawne uprawnienia:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   

5. Otwórz (lub stwórz) plik ~/.ssh/authorized_keys:

   nano ~/.ssh/authorized_keys
   

6. Wklej skopiowaną linię z kluczem publicznym, zapisz plik.
7. Ustaw właściwe prawa dostępu:

   chmod 600 ~/.ssh/authorized_keys
   

Uprawnienia są istotne – jeśli katalog lub plik mają zbyt „luźne” prawa, sshd może odmówić użycia kluczy.

Logowanie z użyciem klucza SSH

Po instalacji klucza możesz przetestować logowanie:

ssh user@host

Jeśli masz więcej niż jeden klucz lub niestandardową nazwę pliku, wskaż klucz wprost:

ssh -i ~/.ssh/moj_klucz_ed25519 user@host

Przy pierwszym użyciu klucza z passphrase pojawi się prośba o jego podanie. Jeśli używasz ssh-agent i dodałeś do niego klucz, passphrase trzeba wpisać tylko raz na sesję agenta.

Konfiguracja klienta SSH w pliku ~/.ssh/config

Przy większej liczbie serwerów opłaca się użyć pliku ~/.ssh/config, żeby skrócić polecenia i ustawić domyślne opcje. Przykładowy wpis:

Host produkcja
    HostName serwer.example.com
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Po takim wpisie zamiast:

ssh -i ~/.ssh/id_ed25519 -p 2222 deploy@serwer.example.com

wystarczy:

ssh produkcja

Można w ten sposób definiować aliasy dla całych środowisk (np. dev, stage, prod) oraz wymuszać konkretne opcje bezpieczeństwa (np. ForwardAgent no).

Bezpieczne przechowywanie i rotacja kluczy

Klucz prywatny to w praktyce „master klucz” do twoich serwerów. Kilka prostych zasad:

• nie wysyłaj klucza prywatnego przez e-mail, komunikatory, itp.,
• rób osobne klucze dla różnych urządzeń (laptop, desktop, serwer CI),
• przy utracie urządzenia – usuń odpowiadające klucze z authorized_keys na serwerach,
• od czas do czasu generuj nowe klucze (rotacja) i usuwaj stare, nieużywane wpisy.

Bezpieczna konfiguracja SSH na serwerze

Podstawowy plik konfiguracyjny: /etc/ssh/sshd_config

Za zachowanie serwera SSH (demona sshd) odpowiada plik /etc/ssh/sshd_config. Modyfikacja tego pliku wymaga uprawnień roota. Standardowy workflow:

1. Zaloguj się na serwer (jeszcze z działającym hasłem / domyślną konfiguracją).
2. Zrób kopię zapasową:

   sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
   

3. Edytuj plik:

   sudo nano /etc/ssh/sshd_config
   

4. Po zmianach wykonaj test składni i restart / reload usługi:

   sudo sshd -t
   sudo systemctl reload sshd   # lub: sudo systemctl restart ssh
   

sshd -t sprawdza poprawność konfiguracji (bez uruchamiania demona). Jeśli zwróci błąd, napraw go przed restartem – w przeciwnym razie możesz zablokować sobie zdalny dostęp.

Wyłączenie logowania roota

Logowanie jako root przez SSH jest wygodne, ale podnosi ryzyko. Lepiej:

• utworzyć zwykłego użytkownika z sudo,
• zablokować zdalne logowanie dla roota.

Tworzenie użytkownika (przykład dla Debiana/Ubuntu):

sudo adduser admin
sudo usermod -aG sudo admin

Następnie zaloguj się testowo jako admin (jeszcze z hasłem lub już z kluczem) i upewnij, że sudo działa:

sudo whoami

W /etc/ssh/sshd_config znajdź linię:

#PermitRootLogin prohibit-password

i zmień na:

PermitRootLogin no

Jeśli linia jest zakomentowana, usuń #. Po reloadzie sshd root nie będzie mógł logować się przez SSH (nawet z kluczem). W razie awarii nadal masz lokalny dostęp przez konsolę (np. przez panel VPS-a).

Wyłączenie logowania hasłem

Gdy klucze są już skonfigurowane i przetestowane, kolejnym krokiem jest odcięcie logowania hasłowego. Zmniejsza to ryzyko skutecznego brute force na hasłach.

W /etc/ssh/sshd_config ustaw:

PasswordAuthentication no
KbdInteractiveAuthentication no

Na niektórych systemach wystarczy samo PasswordAuthentication no, ale klienci potrafią próbować różnych metod, dlatego dodatkowo wyłącza się KbdInteractiveAuthentication.

Po zapisaniu i sshd -t wykonaj:

sudo systemctl reload sshd

Przed rozłączeniem aktualnej sesji otwórz nowy terminal i spróbuj zalogować się jeszcze raz – już tylko kluczem. Jeśli wszystko działa, możesz spokojnie zamykać stare połączenie.

Ograniczenie do wybranych użytkowników lub grup

Na serwerach, na których działa wielu użytkowników, dobrze jest jawnie wskazać, kto może korzystać z SSH. Służą do tego dyrektywy:

• AllowUsers – lista użytkowników (z opcjonalnym @host),
• AllowGroups – lista grup systemowych,
• DenyUsers, DenyGroups – czarne listy.

Prosty wariant, który wpuszcza tylko dwóch adminów:

AllowUsers admin deploy

Albo wariant z grupą:

AllowGroups sshusers

Wtedy wystarczy dopisywać użytkowników do grupy sshusers:

sudo groupadd sshusers        # jednorazowo
sudo usermod -aG sshusers admin
sudo usermod -aG sshusers deploy

Jeśli użyjesz zarówno AllowUsers, jak i AllowGroups, serwer stosuje oba filtry – użytkownik musi spełnić warunki narzucone przez wszystkie dyrektywy.

Zmiana portu SSH – plusy, minusy, praktyka

Domyślny port 22 jest skanowany masowo. Zmiana portu nie jest „prawdziwym” zabezpieczeniem kryptograficznym, ale ogranicza spam w logach i automatyczne próby logowania.

W /etc/ssh/sshd_config ustaw np.:

Port 2222

Po reloadzie usługi trzeba pamiętać o:

• aktualizacji reguł firewalla (otworzyć nowy port, zamknąć stary),
• aktualizacji konfiguracji klientów (~/.ssh/config, pliki deployowe, CI/CD).

Przykład dla firewalla UFW (Ubuntu):

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo systemctl reload sshd

Test po zmianie wykonuj z nowej sesji. W starym oknie trzymaj jeszcze otwarte połączenie na starym porcie, dopóki nie upewnisz się, że nowa konfiguracja działa.

Konfiguracja czasu i liczby prób logowania

Domyślne ustawienia liczby prób hasła i czasu na zalogowanie bywają zbyt łagodne. Nawet jeśli używasz tylko kluczy, agresywni klienci mogą zjadać zasoby serwera.

Przydatne dyrektywy:

• LoginGraceTime – ile czasu (np. 30s) klient ma na ukończenie logowania,
• MaxAuthTries – ile nieudanych prób uwierzytelnienia na sesję,
• MaxSessions – ile równoległych sesji per połączenie (multiplexing).

Rozsądna konfiguracja startowa:

LoginGraceTime 30
MaxAuthTries 3
MaxSessions 4

Przy 3 próbach i wyłączonych hasłach ryzyko przypadkowego zablokowania się jest niskie, a ataki słownikowe są szybko odcinane.

Wymuszanie korzystania z kluczy

Oprócz wyłączenia haseł można jasno zadeklarować, że jedyną formą uwierzytelniania są klucze publiczne:

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

UsePAM (Pluggable Authentication Modules) w wielu dystrybucjach jest włączone; jego wyłączenie ogranicza dodatkowe metody logowania (np. via PAM). Trzeba to robić świadomie, bo integracje typu 2FA przez PAM mogą wymagać pozostawienia UsePAM yes.

Forwardowanie portów (tunneling) – kontrola i bezpieczeństwo

SSH pozwala tunelować inne połączenia sieciowe. To potężne narzędzie, ale bez kontroli może otworzyć niechciane furtki.

Kluczowe opcje w sshd_config:

• AllowTcpForwarding – zezwolenie na forwardowanie TCP (local/remote),
• X11Forwarding – forwardowanie X11 (aplikacje graficzne przez SSH),
• PermitTunnel – tunelowanie w trybie TUN/TAP (VPN-like).

Jeżeli serwer ma jedynie służyć do administracji i nie potrzebujesz tuneli:

AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

Gdy korzystasz np. z tuneli do dostępu do bazy w prywatnej sieci, lepiej zawęzić możliwość forwardowania do wybranych użytkowników. Służy do tego sekcja Match.

Match – różne reguły dla różnych użytkowników i adresów

Sekcja Match pozwala włączać/wyłączać opcje SSH w zależności od użytkownika, grupy, adresu IP czy hosta. Składnia:

Match User deploy
    AllowTcpForwarding yes
    X11Forwarding no

Przykład bardziej złożony – dopuszczamy tunelowanie tylko z zaufanej sieci:

Match User deploy Address 203.0.113.0/24
    AllowTcpForwarding yes

Match User deploy
    AllowTcpForwarding no

Interpretacja: użytkownik deploy może tunelować tylko wtedy, gdy łączy się z adresu w podsieci 203.0.113.0/24. Poza tą siecią forwardowanie jest blokowane.

Ograniczanie komend: ForceCommand i shell ograniczony

Czasem użytkownik SSH wcale nie powinien mieć pełnego shella. Typowe przypadki:

• użytkownik do backupu (może tylko rsync w jedną stronę),
• konto na potrzeby deploymentu z CI (np. tylko git receive-pack lub skrypt deployujący).

Istnieją trzy poziomy „przykręcania śruby”:

ForceCommand w sshd_config

Dla danego użytkownika można wymusić wykonanie konkretnego polecenia niezależnie od tego, co poda klient:

Match User backup
    ForceCommand /usr/local/sbin/backup-wrapper.sh
    AllowTcpForwarding no
    X11Forwarding no

Ten użytkownik po zalogowaniu nie otrzyma normalnego shella – od razu uruchomi się wskazany skrypt. Po jego zakończeniu sesja SSH się zamknie.

Command= w authorized_keys

Jeszcze precyzyjniejszy mechanizm działa na poziomie pojedynczego klucza w authorized_keys:

command="/usr/local/bin/deploy-app.sh",no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAAC3NzaC1... komentarz

Tu konkretne opcje (komenda, zakaz forwardowania) są przypięte bezpośrednio do danego klucza publicznego. Jeśli ten klucz zostanie użyty, serwer zignoruje przesłaną przez klienta komendę i odpali tylko deploy-app.sh.

Ograniczony shell (rbash)

Dodatkową warstwą kontroli może być ograniczony shell, np. rbash (restricted bash). W pliku /etc/passwd dla użytkownika ustawiasz:

backup:x:1002:1002::/home/backup:/bin/rbash

W tym trybie użytkownik ma mocno obcięte możliwości (brak zmiany katalogu, ograniczenia w zmiennych środowiskowych itd.). Dobrze działa to w parze z ForceCommand lub command= w authorized_keys.

Logowanie i audyt połączeń SSH

Przy problemach z logowaniem lub analizie incydentów logi są bezcenne. Demon sshd loguje się do systemowego logera (rsyslog, journald).

Na typowym Debianie/Ubuntu:

• /var/log/auth.log – logi uwierzytelniania,
• journalctl -u ssh lub journalctl -u sshd – logi z jednostki systemd.

Przykładowe komendy diagnostyczne:

sudo tail -f /var/log/auth.log
sudo journalctl -u sshd --since "10 minutes ago"

Jeśli chcesz bardziej szczegółowe logi SSH, w sshd_config ustaw:

LogLevel VERBOSE

Po reloadzie sshd w logach pojawi się więcej informacji, w tym np. fingerprinty kluczy używanych do logowania. Dobre narzędzie przy debugowaniu problemów z kluczami, ale niekoniecznie na stałe w środowisku produkcyjnym (większa ilość logów).

Automatyczne blokowanie nadużyć: Fail2ban i podobne

Same ustawienia sshd to jedno, ale sensownie jest też reagować na powtarzające się nieudane próby logowania z tych samych adresów IP. Robią to narzędzia typu:

• Fail2ban – najczęściej spotykany na serwerach VPS,
• sshguard, crowdsec – alternatywy z podobnym celem.

Zasada działania jest prosta: demon analizuje logi, wykrywa wiele nieudanych logowań z jednego IP i wkłada je na czasową „czarną listę” w firewallu (np. iptables, nftables, UFW).

Instalacja Fail2ban na Debian/Ubuntu:

sudo apt install fail2ban

Podstawowa konfiguracja znajduje się w /etc/fail2ban. Zamiast edytować fail2ban.conf wprost, tworzysz fail2ban.local i nadpisujesz tam wybrane ustawienia. Analogicznie dla jaili: jail.local.

Przykładowy minimalny wpis dla SSH w /etc/fail2ban/jail.local:

[sshd]
enabled  = true
port     = 2222
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 1h
findtime = 10m

Pola maxretry, bantime i findtime określają, ile nieudanych logowań w jakim czasie powoduje blokadę IP i na jak długo. Po zmianach:

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

Stan i aktywne bany można podejrzeć przez:

sudo fail2ban-client status sshd

Hardening kryptograficzny: wybór protokołów i algorytmów

Najczęściej zadawane pytania (FAQ)

Co to jest SSH i czym różni się od Telnetu?

SSH (Secure Shell) to protokół do zdalnego logowania i wykonywania poleceń na innym komputerze z użyciem szyfrowania. Cała komunikacja między twoim komputerem a serwerem jest zaszyfrowana, więc podsłuchujący widzi jedynie nieczytelne pakiety.

Telnet działa podobnie pod względem funkcjonalnym (zdalna konsola), ale przesyła dane w czystym tekście. Oznacza to, że login, hasło oraz treść komend mogą być łatwo podejrzane w sieci, np. na publicznym Wi‑Fi. SSH rozwiązuje ten problem, dodając szyfrowanie i weryfikację tożsamości serwera.

Jak wykonać pierwsze logowanie przez SSH do serwera?

Podstawowa komenda logowania wygląda tak: ssh user@host, np. ssh ubuntu@192.0.2.10. Jeśli serwer nasłuchuje na niestandardowym porcie, dodajesz go parametrem -p, np.: ssh ubuntu@192.0.2.10 -p 2222.

Przy pierwszym połączeniu zobaczysz komunikat z fingerprintem (odciskiem klucza) serwera i pytaniem, czy mu ufasz. Po porównaniu z danymi od dostawcy (np. w panelu hostingu) potwierdzasz yes, a następnie podajesz hasło użytkownika na serwerze. Po poprawnym logowaniu otrzymasz powłokę (shell) zdalnego systemu.

Jak wygenerować i używać kluczy SSH krok po kroku?

Na Linuxie i macOS generujesz parę kluczy poleceniem: ssh-keygen -t ed25519 (lub -t rsa, jeśli potrzebujesz zgodności wstecznej). Narzędzie zapyta o lokalizację pliku (domyślnie ~/.ssh/id_ed25519) i opcjonalne hasło (passphrase) chroniące klucz prywatny.

Po wygenerowaniu masz dwa pliki: klucz prywatny (np. id_ed25519) zostaje wyłącznie na twoim komputerze, a klucz publiczny (np. id_ed25519.pub) kopiujesz na serwer do pliku ~/.ssh/authorized_keys odpowiedniego użytkownika. Od tego momentu możesz logować się bez podawania hasła serwera, wykorzystując tylko swój klucz prywatny.

Jak skonfigurować SSH w Windows (PuTTY vs wbudowany klient)?

W Windows 10/11 masz zazwyczaj wbudowanego klienta SSH w PowerShellu lub CMD, więc możesz użyć tej samej komendy co na Linuxie: ssh user@host -p 2222. Klucze generujesz poleceniem ssh-keygen, a pliki lądują w katalogu C:UsersNazwaUżytkownika.ssh.

Jeśli wolisz PuTTY, najpierw generujesz klucz w PuTTYgen, zapisujesz plik klucza prywatnego .ppk na dysku, a zawartość pola „Public key” wklejasz na serwer do ~/.ssh/authorized_keys. W samym PuTTY ustawiasz adres hosta, port, a w sekcji „Connection > SSH > Auth” wskazujesz plik klucza prywatnego.

Jak połączyć się przez SSH bez hasła, tylko z użyciem klucza?

Najpierw generujesz parę kluczy na swoim komputerze (ssh-keygen), a potem kopiujesz klucz publiczny na serwer. Najprościej: ssh-copy-id user@host (Linux/macOS) – narzędzie samo dopisze klucz do ~/.ssh/authorized_keys na serwerze.

Po tej operacji możesz zalogować się komendą ssh user@host bez podawania hasła do konta na serwerze. Jeśli klucz prywatny zabezpieczony jest passphrase, wpisujesz tylko to hasło lokalnie; serwer nie zna i nie przechowuje twojego klucza prywatnego.

Jakie ustawienia w pliku sshd_config poprawiają bezpieczeństwo SSH?

Plik /etc/ssh/sshd_config kontroluje działanie serwera SSH (sshd). Do podstawowych ustawień podnoszących bezpieczeństwo należą m.in.:

• PermitRootLogin no – wyłączenie bezpośredniego logowania na konto root.
• PasswordAuthentication no – wyłączenie logowania hasłem, zostaje tylko logowanie kluczem.
• Port 2222 (lub inny) – zmiana domyślnego portu 22 na niestandardowy.

Po zmianach trzeba przeładować usługę, np. systemctl reload sshd. Uwaga: wyłączaj logowanie hasłem dopiero wtedy, gdy klucze na pewno działają, inaczej możesz odciąć sobie dostęp do serwera.

Jakie są typowe błędy przy korzystaniu z SSH i jak ich uniknąć?

Najczęstsze problemy to: błędne uprawnienia do katalogu ~/.ssh i pliku authorized_keys (SSH odrzuca zbyt „otwarte” prawa), brak zgodności nazwy użytkownika (root vs ubuntu), zły port lub blokada na firewallu. Dobry start to sprawdzenie komendą ssh -v user@host, która pokaże szczegółowy log połączenia.

Druga kategoria błędów to nadmierne „utwardzanie” konfiguracji: zbyt agresywne zmiany w sshd_config bez aktywnej sesji awaryjnej lub wyłączenie wszystkich metod logowania w jednym kroku. Bezpieczna praktyka: po każdej większej zmianie najpierw nie restartuj usługi, tylko zrób reload i od razu przetestuj nowe połączenie w osobnym oknie.

Najważniejsze punkty

• SSH zastąpił Telnet, bo szyfruje całą komunikację (logowanie, komendy, treść plików, tunelowany ruch), dzięki czemu podsłuchujący widzi tylko nieczytelne pakiety zamiast jawnego tekstu.
• Podstawowy cel początkującego użytkownika SSH to bezpieczne logowanie do serwera (najlepiej bezhasłowe z użyciem kluczy) oraz unikanie konfiguracji, które unieruchomią lub odsłonią serwer na ataki.
• Połączenie SSH opisują trzy kluczowe parametry: użytkownik w systemie (np. root, ubuntu), host (IP lub domena) oraz port TCP (domyślnie 22, często zmieniany np. na 2222 dla ograniczenia skanów botów).
• SSH opiera się na kryptografii asymetrycznej: klucz prywatny zostaje na twojej maszynie, klucz publiczny trafia na serwer; serwer akceptuje tylko tego klienta, który potrafi udowodnić, że posiada pasujący klucz prywatny.
• Klient SSH (ssh) inicjuje połączenie i uzgadnia szyfrowanie, a serwer SSH (sshd) nasłuchuje na porcie, weryfikuje klucz hosta, uwierzytelnia użytkownika i po sukcesie uruchamia powłokę lub wybrane polecenie.
• SSH służy nie tylko do zdalnego logowania, ale też do tunelowania ruchu (port forwarding), np. bezpiecznego dostępu do bazy danych czy wewnętrznego panelu admina bez wystawiania ich na publiczny internet.

Źródła informacji

• RFC 4251: The Secure Shell (SSH) Protocol Architecture. Internet Engineering Task Force (2006) – Specyfikacja architektury protokołu SSH, pojęcia klient/serwer, szyfrowanie
• RFC 4252: The Secure Shell (SSH) Authentication Protocol. Internet Engineering Task Force (2006) – Metody uwierzytelniania w SSH, w tym klucze publiczne i hasła
• OpenSSH Manual Pages: ssh, sshd, ssh-keygen. OpenBSD Project – Dokumentacja narzędzi klienckich i serwera SSH, opcje, konfiguracja, klucze
• Secure Shell (SSH) – NIST Special Publication 800-123. National Institute of Standards and Technology (2008) – Wytyczne bezpieczeństwa dla zdalnego zarządzania, SSH jako bezpieczna alternatywa Telnetu