Ubuntu: jak włączyć SSH i zabezpieczyć serwer OpenSSH

Włączanie SSH w Ubuntu: instalacja, start, otwarcie zapory

SSH w Ubuntu pochodzi z pakietu openssh-server. Ubuntu Server proponuje jego instalację podczas konfiguracji, a niemal każdy obraz chmurowy lub VPS dostarcza go już nasłuchującego; Ubuntu Desktop nie instaluje go wcale.

1. Zainstaluj openssh-server

sudo apt update
sudo apt install -y openssh-server

Jeśli pakiet już istnieje, apt to zgłosi i niczego nie zmieni. Instalacja rejestruje też profil aplikacji UFW o nazwie OpenSSH, używany w kroku 3.

2. Włącz i uruchom usługę

sudo systemctl enable --now ssh
systemctl status ssh

W Ubuntu jednostka nazywa się ssh; sshd to alias. enable --now uruchamia demona teraz i przy każdym starcie systemu. Od Ubuntu 22.10 sshd jest aktywowany przez gniazdo: ssh.socket zajmuje port 22 i uruchamia ssh.service przy pierwszym przychodzącym połączeniu, więc status inactive (dead) z TriggeredBy: ssh.socket zaraz po instalacji jest normalny, bo port jest otwarty. Szerszy obraz znajdziesz w liście usług przez systemctl.

3. Przepuść SSH przez UFW

Ubuntu dostarcza UFW wyłączone. Jeśli je włączasz, najpierw zezwól na SSH; włączenie zapory przed dodaniem reguły to klasyczny sposób na odcięcie sobie dostępu do zdalnej maszyny.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

ufw allow OpenSSH korzysta z profilu aplikacji i otwiera 22/tcp. Jeśli później przeniesiesz sshd, zezwól na nowy port poleceniem sudo ufw allow 2222/tcp i usuń starą regułę. Adres serwera sprawdzisz przez hostname -I.

Łączenie z Windows, macOS lub Linux

Każdy współczesny system desktopowy ma wbudowanego klienta OpenSSH, a składnia jest wszędzie identyczna:

ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP      # non-default port

• Windows 10 i 11: otwórz PowerShell lub Windows Terminal i wpisz polecenie; klient OpenSSH jest częścią Windows od 2018 roku (wersja 1809). Jeśli ssh nie jest rozpoznawane, dodaj je w Ustawienia > Aplikacje > Funkcje opcjonalne.
• macOS: Terminal, to samo polecenie.
• Linux: dowolny terminal; openssh-client jest w Ubuntu instalowany domyślnie.

Przy pierwszym połączeniu zaakceptuj odcisk klucza hosta wpisując yes; zostanie zapisany w ~/.ssh/known_hosts, a każda późniejsza zmiana wywoła ostrzeżenie. Następnie wpisz hasło konta. Kolejna sekcja zastępuje je kluczem.

Przejście na uwierzytelnianie kluczem

To właśnie logowanie hasłem botnety atakują metodą brute force przez całą dobę; klucze czynią te próby bezcelowymi. Wygeneruj parę kluczy Ed25519 na swoim komputerze, nigdy na serwerze:

ssh-keygen -t ed25519 -C "laptop-2026"

Zaakceptuj domyślną ścieżkę (~/.ssh/id_ed25519) i ustaw hasło (passphrase); szyfruje ono klucz prywatny na dysku, a agent SSH sprawia, że wpisujesz je raz na sesję. Twoją maszynę opuszcza wyłącznie plik .pub.

Skopiuj klucz publiczny na serwer

W macOS i Linuksie ssh-copy-id robi to w jednym kroku, używając hasła po raz ostatni:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IP

Windowsowa wersja OpenSSH nie zawiera ssh-copy-id; zamiast tego prześlij klucz potokiem z PowerShella:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Obie metody dopisują klucz do pliku ~/.ssh/authorized_keys danego użytkownika. Uprawnienia mają znaczenie: sshd po cichu ignoruje plik, gdy ~/.ssh nie ma trybu 700 lub gdy authorized_keys jest zapisywalny dla kogokolwiek poza właścicielem. W nowym terminalu ssh username@SERVER_IP powinno teraz zalogować cię bez hasła konta. Nie przechodź do kolejnej sekcji, dopóki to nie zadziała.

Hartowanie sshd_config: bez haseł, bez roota, z listą dozwolonych użytkowników

Podczas edycji zostaw otwartą bieżącą sesję; jeśli nowa konfiguracja coś zepsuje, to twoja droga powrotna. Plik /etc/ssh/sshd_config zaczyna się od Include /etc/ssh/sshd_config.d/*.conf, a sshd zachowuje pierwszą odczytaną wartość dla każdego słowa kluczowego, więc plik drop-in wygrywa z czymkolwiek dalej w pliku głównym. Do tego obrazy chmurowe często dostarczają /etc/ssh/sshd_config.d/50-cloud-init.conf z PasswordAuthentication yes, dlatego edycja głównego pliku tak często wydaje się nie działać. Rozwiązaniem jest drop-in o nazwie sortującej się jako pierwsza:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Wklej poniższe, zamieniając username na własny login:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

PermitRootLogin no zakłada, że masz nieuprzywilejowane konto z prawami sudo. Jeśli do tej pory pracowałeś jako root, utwórz użytkownika sudo w Linuksie i skopiuj do niego swój klucz przed zastosowaniem pliku. Następnie sprawdź składnię, przeładuj usługę i zobacz wartości, których sshd faktycznie używa po scaleniu wszystkich dołączeń. To właśnie wypisuje sshd -T:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'

Otwórz drugi terminal i zaloguj się kluczem, zanim zamkniesz pierwszy. Co robi każda dyrektywa:

Keepalive ma też stronę kliencka: ServerAliveInterval 60 w ~/.ssh/config na twojej maszynie powstrzymuje routery NAT przed zrywaniem bezczynnych sesji.

Zmiana portu SSH to nie zabezpieczenie

Przeniesienie sshd z portu 22 to popularna rada. Zyskujesz mniej linii w logach. Masowe skanery przeczesują wszystkie 65 535 portów i znajdują sshd na 2222 w ciągu godzin; ktoś, kto celuje w ciebie, znajdzie go w sekundy przy użyciu nmap. Zabezpieczeniem są klucze, brak logowania roota, lista dozwolonych i fail2ban; port jest kosmetyką. Na obciążonym serwerze wciąż pomaga, bo utrzymuje log uwierzytelniania w czytelnej formie, tylko nigdy nie traktuj tego jako warstwy obrony.

Jeśli jednak go zmieniasz, zachowaj tę kolejność: otwórz nowy port w UFW, zmień port, zrestartuj, przetestuj z drugiego terminala, dopiero potem usuń starą regułę. Odkomentuj #Port 22 w /etc/ssh/sshd_config, ustaw nowy port, a następnie:

sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket    # Ubuntu 22.10 and later
sudo systemctl restart ssh           # Ubuntu 22.04 and earlier

W wydaniach z aktywacją przez gniazdo to jednostka gniazda, a nie sshd, decyduje o wiązanym porcie; Ubuntu dostarcza generator systemd, który odczytuje Port z konfiguracji sshd podczas daemon-reload i aktualizuje ssh.socket. Potwierdź poleceniem sudo ss -tlnp | grep sshd. Poradnik o sprawdzaniu otwartych portów w Linuksie wyjaśnia jego wynik. Jeśli sshd uparcie trzyma się portu 22, wyłącz aktywację przez gniazdo i pozwól usłudze samodzielnie zająć port: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. Gdy ssh -p 2222 zadziała z nowego terminala, wykonaj sudo ufw delete allow OpenSSH.

Dodaj fail2ban i rozważ uwierzytelnianie dwuskładnikowe

Przy wyłączonych hasłach brute force nie może się powieść, ale każda próba nadal kosztuje jeden proces i jedną linię logu. fail2ban obserwuje log uwierzytelniania i banuje adresy, które wielokrotnie zawodzą:

sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.local

Umieść w pliku to:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Nigdy nie edytuj jail.conf; jest podmieniany przy aktualizacjach, a jail.local go nadpisuje. port = ssh rozwiązuje się przez /etc/services, więc wpisz port = 2222, jeśli przeniosłeś demona. backend = systemd czyta dziennik bezpośrednio i działa niezależnie od tego, czy twój obraz zapisuje /var/log/auth.log. fail2ban-client status sshd wypisuje zbanowane adresy; sudo fail2ban-client set sshd unbanip 203.0.113.7 zdejmuje bana. Domyślnie reguły fail2ban są przetwarzane przed regułami UFW, więc oba współistnieją.

Uwierzytelnianie dwuskładnikowe

Tam, gdzie klucz z hasłem to za mało, libpam-google-authenticator dokłada kod czasowy na wierzchu klucza: zainstaluj pakiet, uruchom google-authenticator jako użytkownik logowania, dodaj auth required pam_google_authenticator.so do /etc/pam.d/sshd (i zakomentuj tam linię @include common-auth), a następnie ustaw w sshd KbdInteractiveAuthentication yes i AuthenticationMethods publickey,keyboard-interactive. Realny zysk wobec skradzionego laptopa i jedna rzecz więcej do zgubienia: trzymaj kody zapasowe poza serwerem.

Rozwiązywanie problemów: connection refused, timed out, permission denied

Connection refused

Serwer odpowiedział, ale nic nie nasłuchuje na tym porcie: sshd jest zatrzymany, związany z innym portem albo wpisałeś zły port. Z konsoli dostawcy wykonaj systemctl status ssh i sudo ss -tlnp | grep ssh. Błąd składni całkowicie uniemożliwia start sshd; sudo sshd -t wypisuje problematyczną linię, a journalctl -u ssh -n 50 pokazuje ostatni start.

Connection timed out

Pakiety są odrzucane po cichu, a nie odbijane, co niemal zawsze oznacza zaporę: UFW bez reguły zezwalającej (sudo ufw status verbose), grupa bezpieczeństwa w panelu dostawcy albo twoja własna sieć blokująca wychodzący port 22. Hotspot z telefonu to wyklucza. ssh -v username@SERVER_IP pokazuje, gdzie zawiesza się handshake.

Permission denied (publickey)

Serwer jest osiągalny i cię odrzuca. Sprawdź po kolei: nazwę użytkownika, czy plik authorized_keys tego użytkownika zawiera klucz, który oferujesz (ssh -i ~/.ssh/id_ed25519 -v wymusza konkretny klucz), uprawnienia do ~/.ssh oraz czy login nie brakuje w AllowUsers. Na serwerze journalctl -u ssh -n 30 poda powod; Authentication refused: bad ownership or modes to opisany wcześniej problem z uprawnieniami.

Ostrzeżenie o kluczu hosta

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED po odtworzeniu serwera jest oczekiwane: wykonaj ssh-keygen -R SERVER_IP i połącz się ponownie. Jeśli niczego nie instalowałeś od nowa, ustal przyczynę, zanim gdziekolwiek wpiszesz hasło. Całkowicie odcięty? Konsola dostawcy to droga powrotna.

Wszystko powyższe zakłada maszynę, na której masz roota i możesz sobie pozwolić na zepsucie sshd i naprawę z konsoli. Linux VPS od rdp.monster to dokładnie taka maszyna: pełny dostęp root, dedykowany CPU i RAM, nielimitowane pasmo (fair-use), bez KYC, płatność kryptowalutą lub walutą fiat, od $8.99 miesięcznie, a serwer jest online około 10 sekund po potwierdzeniu płatności, czyli dość czasu, by mieć klucze na miejscu, zanim pierwszy skaner znajdzie port 22.

Najczęściej zadawane pytania

Czy Ubuntu ma SSH włączone domyślnie?

Ubuntu Desktop nie; Ubuntu Server i większość obrazów chmurowych tak.

Ubuntu Desktop instaluje wyłącznie klienta SSH, więc nic nie nasłuchuje na porcie 22, dopóki nie wykonasz sudo apt install openssh-server. Ubuntu Server pyta podczas instalacji, czy zainstalować serwer OpenSSH, i może przy okazji zaimportować twoje klucze z GitHuba lub Launchpada. Obrazy chmurowe i VPS niemal zawsze mają openssh-server zainstalowany, włączony i przyjmujący połączenia, bo to jedyny sposób, w jaki dostawca może przekazać ci maszynę. Sprawdź poleceniem systemctl status ssh.

Jak sprawdzić, czy SSH działa w Ubuntu?

Wykonaj systemctl status ssh, a potem potwierdź nasłuch na porcie 22 przez ss.

systemctl status ssh mówi, czy usługa jest aktywna lub włączona przy starcie. Ponieważ Ubuntu 22.10 i nowsze używają aktywacji przez gniazdo, usługa może zgodnie z prawdą pokazywać inactive (dead) z TriggeredBy: ssh.socket, gdy nikt nie jest połączony, więc pewniejszym testem jest sudo ss -tlnp | grep ssh: linia z 0.0.0.0:22 lub [::]:22 oznacza, że SSH nasłuchuje. Z innej maszyny ssh -v username@SERVER_IP potwierdza to od końca do końca.

Czy zostawienie SSH na porcie 22 jest bezpieczne?

Tak, o ile hasła są wyłączone i używasz kluczy; numer portu nie dodaje ochrony.

Port 22 przyciąga nieustanne automatyczne próby logowania, ale nie mogą się one powieść na serwerze z PasswordAuthentication no i parą kluczy, a fail2ban usuwa większość hałasu. Przeniesienie sshd na 2222 lub 22222 ukrywa go tylko przed najbardziej leniwymi skanerami; skanery portów takie jak nmap i masscan znajdują go w kilka minut, a ogólnointernetowe indeksy i tak go wymieniają. Traktuj niestandardowy port jako higienę logów, a nie środek bezpieczeństwa, i nigdy nie rezygnuj z kluczy dlatego, że zmieniłeś port.

Jaka jest różnica między ssh a sshd w Ubuntu?

ssh to program kliencki; sshd to demon serwera, którego jednostka w Ubuntu nazywa się ssh, z sshd jako aliasem.

ssh to klient, który uruchamiasz na laptopie, aby otworzyć połączenie; pochodzi z pakietu openssh-client. sshd to demon odpowiadający na serwerze, z pakietu openssh-server, konfigurowany w /etc/ssh/sshd_config (klient czyta ssh_config). Ubuntu i Debian nazywają jednostkę systemd ssh.service i deklarują sshd.service jako alias, więc systemctl restart ssh i systemctl restart sshd robią to samo; w Fedorze, RHEL i Arch jednostka nazywa się po prostu sshd.