Zmiana portu SSH bez utraty dostępu: sshd, aktywacja przez socket i SELinux

Zmiana portu SSH to jedna z najczęściej powtarzanych i najgorzej uzasadnianych porad w administracji serwerami. Ma realny sens, tylko inny niż ten, który zwykle się jej przypisuje, i ma skutek uboczny: między chwilą, w której usługa zwalnia stary port, a chwilą, w której nowy jest już osiągalny przez wszystkie filtry pakietów, powstaje luka. Kto jej nie zaplanuje, ten na nią trafi.

Ten poradnik przeprowadza zmianę tak, żeby ta luka w ogóle nie powstała: podczas przebudowy serwer nasłuchuje jednocześnie na starym i na nowym porcie, a stary znika dopiero wtedy, gdy nowy udowodni, że działa.

Wszystkie informacje dotyczą Debiana 13 (trixie), Debiana 12 (bookworm), Ubuntu 24.04 LTS oraz Ubuntu 22.04 LTS. Osobna sekcja opisuje SELinuksa na systemach RHEL, czyli AlmaLinux i Rocky Linux. Polecenia zapisano z myślą o pracy jako root. Jeśli pracujesz jako zwykły użytkownik, dopisz przed każdym poleceniem sudo. Jako przykładowy port służy 2222, jako przykładowy adres 203.0.113.10.

Co daje inny port, a czego nie daje

Żadnego zysku na bezpieczeństwie. Pełne skanowanie wszystkich 65 535 portów i tak znajdzie usługę, a identyfikator wersji, który OpenSSH wysyła przy nawiązywaniu połączenia, także na porcie 51022 od razu zdradza, z czym ma się do czynienia. Zmiana portu nie zastępuje żadnego ze środków, które naprawdę działają: logowania kluczem zamiast hasłem, wyłączonego logowania hasłem ani wąsko ustawionego filtra pakietów.

Mniej szumu w logach, a to całkiem sporo. Przeważająca część tego, co trafia na port 22, to niecelowane skanowanie masowe. Te narzędzia próbują portu 22 i niczego więcej, bo pełny skan całego internetu po prostu się nie opłaca. Kiedy przeniesiesz usługę, ta klasa ruchu znika z dziennika, a pojedyncza, celowana próba logowania w ogóle zaczyna rzucać się w oczy.

Koszty, które trzeba wliczyć. Każde narzędzie potrzebuje odtąd podanego portu: skrypty backupu, przebiegi deploymentu, monitoring. I jeszcze jedna rzecz, którą prawie wszystkie poradniki przemilczają: sieci firmowe, hotelowe Wi-Fi i część taryf komórkowych przepuszczają na zewnątrz tylko kilka portów, najczęściej 22, 80 i 443. Z takich sieci możesz potem w ogóle nie dostać się na swój serwer.

Krótko: zrób to, jeśli chcesz mieć spokojne logi. Nie rób tego w przekonaniu, że rozwiązujesz w ten sposób problem bezpieczeństwa.

Droga powrotna, zanim cokolwiek zmienisz

1. Otwórz raz konsolę w panelu klienta

Każdy serwer root KVM i każdy serwer dedykowany w KernelHoście ma w panelu klienta konsolę VNC. Jest podpięta pod wyjście obrazu systemu i działa niezależnie od stosu sieciowego serwera, więc błędna reguła firewalla nie jest w stanie jej zablokować. Zaloguj się tam raz zawczasu i upewnij się, że znasz hasło roota. Droga ratunkowa, którą testuje się dopiero w sytuacji awaryjnej, żadną drogą ratunkową nie jest.

2. Dwie sesje, a pierwsza zostaje otwarta

Zaloguj się drugi raz, zanim zaczniesz. Istniejące połączenia SSH przeżywają zarówno restart usługi, jak i zamknięcie starego portu na firewallu, bo stan połączenia jest już ustanowiony. Zachowasz więc działającą powłokę roota nawet wtedy, gdy dla nowych połączeń dawno już się zablokowałeś. I to jest właśnie ta pułapka: wszystko wygląda w porządku, dopóki nie zamkniesz okna.

3. Wyłącznik czasowy, który sam cofa zmianę

Gdyby obie sesje padły, na przykład przez awarię twojego łącza, to zadanie wycofa zmianę portu po piętnastu minutach:

systemd-run --on-active=15min --unit=ssh-portrollback /bin/sh -c 'rm -f /etc/ssh/sshd_config.d/20-port.conf /etc/systemd/system/ssh.socket.d/override.conf; systemctl daemon-reload; systemctl try-restart ssh.socket ssh.service'

Kontrola: systemctl list-timers ssh-portrollback.timer pokazuje moment wyzwolenia. Jeśli wszystko zadziałało, przerwij to zadanie, inaczej twoja zmiana cofnie się później w środku normalnej pracy:

systemctl stop ssh-portrollback.timer

Kolejność, która nie zamyka ci dostępu

Ta sekwencja jest ułożona tak, żeby w żadnym momencie stara droga nie była już zamknięta, a nowa jeszcze nieotwarta.

1. Wybierz port i sprawdź, czy jest wolny.
2. Najpierw firewall: otwórz nowy port, stary zostaw otwarty.
3. Ustaw sshd tak, żeby nasłuchiwał na obu portach.
4. Przy aktywacji przez socket dostosuj dodatkowo jednostkę socketa.
5. Zrestartuj usługę i sprawdź otwarty socket.
6. Zaloguj się trzecią, świeżo otwartą sesją przez nowy port.
7. Dopiero teraz usuń port 22 i dostosuj narzędzia.

Krok 1: wybór portu

Tylko nie 2222. Ten port jest najczęstszym wyborem zastępczym i skanery masowe od dawna sprawdzają go razem z dwudziestką dwójką. Używamy go tutaj wyłącznie jako czytelnego przykładu.

Zostań poniżej 32768. Zakres, z którego jądro przydziela porty źródłowe dla połączeń wychodzących, znajdziesz tutaj:

cat /proc/sys/net/ipv4/ip_local_port_range

Typowe wyjście to 32768 60999. Port z tego zakresu może zostać tymczasowo zajęty przez połączenie wychodzące. Najczęściej kończy się to dobrze, ale po restarcie, gdy inne usługi startują przed sshd, próba przypisania kończy się komunikatem Address already in use, a serwer wstaje bez SSH. Zdarza się to sporadycznie i jest wyjątkowo nieprzyjemne do namierzenia.

Port poniżej 1024 ma realną zaletę. Porty poniżej 1024 może zająć wyłącznie root. Jeśli sshd padnie, żaden nieuprzywilejowany użytkownik nie podepnie się w to miejsce i nie uruchomi podstawionej usługi SSH, która zapisywałaby dane logowania. Przy wielu kontach użytkowników to konkretny argument, przy jednym administratorze raczej teoria.

Kontrola: port nie może być ani zajęty, ani zarezerwowany dla usługi, którą chcesz później uruchomić. Oba polecenia nie powinny niczego wypisać:

ss -tlnp | grep -E ':2222 '
grep -w 2222 /etc/services

Krok 2: najpierw firewall

Ten krok wykonujesz przed konfiguracją sshd, nie po niej. Otwarty port bez usługi za nim jest nieszkodliwy, usługa bez otwartego portu zamyka ci dostęp.

ufw allow 2222/tcp comment 'SSH nowy'
ufw status verbose

Kontrola: w wyniku muszą teraz stać oba porty, każdy po dwa razy, raz dla IPv4 i raz z dopiskiem (v6). Jeśli brakuje wiersza IPv6, nowy port nie jest osiągalny po IPv6, a nowoczesne klienty próbują najpierw właśnie IPv6. Szczegóły znajdziesz w naszym poradniku o firewallu UFW.

Jeśli utrzymujesz nftables ręcznie, dopisz port w swoim pliku reguł, przeładuj go i sprawdź wczytany zestaw reguł poleceniem nft list ruleset | grep 2222. Na systemach RHEL z firewalld:

firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload
firewall-cmd --list-ports

Dwa miejsca umykają uwadze. Po pierwsze fail2ban: jeśli zadziała tam blokada, po zmianie nadal będzie blokować wyłącznie port 22, podczas gdy próby na nowym porcie przechodzą bez przeszkód. Dopisz port w /etc/fail2ban/jail.local:

[sshd]
enabled = true
port    = 2222

Wykrywanie działa dalej, bo fail2ban czyta próby logowania z dziennika i nie wiąże ich z portem. Od tego wiersza zależy tylko sama blokada, zobacz nasz poradnik o fail2ban. Po drugie filtr pakietów stojący przed serwerem, poza nim samym, inaczej będziesz szukać błędu w złym miejscu.

Krok 3: sshd_config i pułapka sshd_config.d

Nie ruszaj /etc/ssh/sshd_config. Wszystkie cztery systemy czytają dodatkową konfigurację z /etc/ssh/sshd_config.d/, a własny plik w tym katalogu przeżywa aktualizacje pakietów bez żadnych pytań. Najpierw sprawdź, co już tam jest:

ls -l /etc/ssh/sshd_config.d/
grep -n '^Include' /etc/ssh/sshd_config

Wiersz Include stoi w Debianie i Ubuntu fabrycznie na samej górze, zwykle w wierszu 12. To ważniejsze, niż wygląda: przy większości dyrektyw wygrywa pierwsza znaleziona wartość, a nie ostatnia. Ponieważ Include stoi na górze, pliki z tego katalogu biją wszystko, co następuje niżej w sshd_config. Jeśli ktoś przesunął go na koniec pliku, sytuacja się odwraca i twój plik zostaje bez efektu.

Przy Port obowiązuje wyjątek i to właśnie on umożliwia bezpieczną zmianę: kilka wierszy Port nie zastępuje się nawzajem, tylko się sumuje. sshd nasłuchuje wtedy na wszystkich wymienionych portach. Równie ważna jest druga strona medalu: wartość domyślna 22 obowiązuje tylko dopóty, dopóki nie istnieje żaden wiersz Port. W chwili gdy dopiszesz pierwszy, port 22 znika, o ile go wyraźnie nie wymienisz.

tee /etc/ssh/sshd_config.d/20-port.conf >/dev/null <<'EOF'
Port 22
Port 2222
EOF
chmod 644 /etc/ssh/sshd_config.d/20-port.conf

Kontrola: najpierw składnia, potem obowiązująca konfiguracja całościowa z rozwiniętymi plikami Include:

sshd -t
sshd -T | grep -E '^(port|listenaddress) '

Spodziewaj się dwóch wierszy: port 22 oraz port 2222. Jeśli pojawi się dodatkowo wiersz listenaddress, to drugie miejsce, w którym mogą stać porty: ListenAddress może podać adres razem z portem i wtedy zawęża to, na czym usługa nasłuchuje. Przeoczony wiersz w rodzaju ListenAddress 127.0.0.1 wyjaśnia większość przypadków, w których port jest skonfigurowany poprawnie, ale z zewnątrz i tak nikt się nie dobija.

Jeśli zamiast tego sshd -t zgłosi Missing privilege separation directory: /run/sshd, usługa nie działała ani razu od startu systemu, a mkdir -p /run/sshd usuwa ten problem.

Krok 4: aktywacja przez socket, gdy portu nie ma w sshd_config

Tutaj drogi dystrybucji się rozchodzą i tutaj zdarza się najwięcej wypadków. Ubuntu od wersji 22.10 stawia na aktywację przez socket: portu nie trzyma sshd, tylko systemd. To on nasłuchuje zastępczo i dopiero przy przychodzącym połączeniu uruchamia proces sshd. Port stoi wtedy w jednostce ssh.socket pod ListenStream, a wiersz Port w konfiguracji sshd może zostać bez efektu.

Nie zgaduj, tylko zapytaj system:

systemctl is-enabled ssh.socket ssh.service

Tabela opisuje stan fabryczny, niekoniecznie twój serwer: obrazy z różnych źródeł potrafią się różnić, a system po aktualizacji zachowuje dotychczasowe ustawienie. Jeśli ssh.socket jest aktywny, systemctl cat pokaże jednostkę razem ze wszystkimi plikami uzupełniającymi i ich ścieżkami, także tymi generowanymi automatycznie:

systemctl cat ssh.socket

Nowy port zapiszesz jako własny plik uzupełniający. Pierwszy, pusty wiersz ListenStream= kasuje dotychczasowe wartości, dalej liczą się już wyłącznie twoje. Bez tego wiersza zerującego wartości fabryczne doszłyby dodatkowo do listy:

mkdir -p /etc/systemd/system/ssh.socket.d
tee /etc/systemd/system/ssh.socket.d/override.conf >/dev/null <<'EOF'
[Socket]
ListenStream=
ListenStream=0.0.0.0:22
ListenStream=[::]:22
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222
EOF
systemctl daemon-reload

Także tutaj oba porty stoją obok siebie, z tego samego powodu co w kroku 3. Plik w /etc/systemd/system/ ma pierwszeństwo przed wszystkim, co system generuje sam.

Kontrola: systemctl cat ssh.socket wypisuje teraz twój plik jako osobny blok.

Jeśli ssh.service i ssh.socket są aktywne jednocześnie, biją się o ten sam port. Objawia się to komunikatem fatal: Cannot bind any address. albo ssh.socket: Socket service ssh.service already active, refusing. Zdecyduj się wtedy na jeden z dwóch trybów pracy, tło opisuje nasz poradnik o zabezpieczaniu SSH.

Krok 5: restart i kontrola na sockecie

Jedno polecenie, poprawne na wszystkich czterech systemach, bo try-restart restartuje tylko to, co faktycznie działa, i zostawia drugą jednostkę nietkniętą:

sshd -t && systemctl try-restart ssh.socket ssh.service

Nie używaj reload: na systemach z aktywacją przez socket kwituje to komunikatem fatal: Cannot bind any address., a usługa zwalnia potem swój port. Nie używaj też samego systemctl restart ssh.socket: na Debianie się nie powiedzie, a na Ubuntu 22.04 niepostrzeżenie przestawi hosta na tryb socketowy. Istniejące sesje przeżywają restart w każdym przypadku.

Kontrola, i to jedyna, która naprawdę się liczy:

ss -tlnp | grep -E ':(22|2222) '

Spodziewaj się czterech wierszy: 0.0.0.0:22, [::]:22, 0.0.0.0:2222 i [::]:2222. Jeśli brakuje wierszy IPv6, nie dosięgniesz serwera po IPv6.

Pewna właściwość potrafi wywołać niepotrzebną panikę: przy aktywacji przez socket w ostatniej kolumnie może stać systemd zamiast sshd, bo to systemd trzyma nasłuchujący socket, dopóki nie działa żaden proces sshd. Filtruj więc po numerze portu, a nie po nazwie procesu, inaczej uznasz działającą usługę za martwą.

Krok 6: trzecia sesja, czyli właściwy test

Teraz, i ani o krok wcześniej, otwórz nowy terminal. Obie stare sesje zostają otwarte.

ssh -p 2222 root@203.0.113.10

Jeśli to nie zadziała, ssh -vv -p 2222 root@203.0.113.10 pokaże, w którym miejscu proces się wykłada.

Jedno pytanie jest przy tym normalne: SSH ponownie pyta o autentyczność klucza hosta, chociaż na serwerze nic się nie zmieniło. Wpisy w known_hosts są bowiem powiązane z portem i dla portów innych niż domyślny zapisują się w postaci [203.0.113.10]:2222. Sprawdź je i w razie wątpliwości usuń:

ssh-keygen -F '[203.0.113.10]:2222'
ssh-keygen -R '[203.0.113.10]:2222'

Czy przebudowa przetrwa restart, najlepiej sprawdź właśnie teraz. Dzięki wciąż otwartej regule dla portu 22 jest to bezpieczne.

Krok 7: zamknięcie portu 22 i dostosowanie narzędzi

Stary port usuwasz dopiero wtedy, gdy krok 6 zadziałał. W 20-port.conf zostaje już tylko jeden wiersz:

tee /etc/ssh/sshd_config.d/20-port.conf >/dev/null <<'EOF'
Port 2222
EOF
sshd -t && systemctl try-restart ssh.socket ssh.service

Przy aktywacji przez socket wykreśl dodatkowo oba wiersze z portem 22 z pliku /etc/systemd/system/ssh.socket.d/override.conf i wykonaj potem systemctl daemon-reload. Następnie firewall:

ufw delete allow 22/tcp
ufw status verbose

Kontrola: ss -tlnp | grep -E ':(22|2222) ' pokazuje teraz już tylko nowy port, znowu w obu rodzinach adresów.

Zostaje część, która ciągnie się najdłużej: wszystkie narzędzia, które łączą się z serwerem. Najwygodniej załatwisz to raz na zawsze w ~/.ssh/config:

Host moj-serwer
    HostName 203.0.113.10
    Port 2222
    User kernel

Wszędzie tam, gdzie podajesz adres bezpośrednio, potrzebujesz podania portu, a zapis różni się w zależności od narzędzia. To klasyczne miejsce potknięcia:

rsync --port dotyczy przy okazji demona rsync, a nie SSH, więc tutaj nie ma żadnego działania. W Ansible port zapisujesz w inwentarzu jako ansible_port.

SELinux na systemach RHEL

Na AlmaLinux, Rocky Linux i RHEL SELinux pracuje fabrycznie w trybie enforcing, a zestaw reguł pozwala sshd wyłącznie na porty oznaczone jako ssh_port_t. Fabrycznie jest to sam port 22. Bez tego dodatkowego kroku usługa nie wystartuje, a komunikat myląco wygląda na problem z uprawnieniami:

error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.

Najpierw spójrz na stan i na istniejące oznaczenia:

getenforce
semanage port -l | grep ssh_port_t

Jeśli brakuje semanage, znajdziesz je w pakiecie policycoreutils-python-utils:

dnf install -y policycoreutils-python-utils

Dodaj nowy port, i to zanim zrestartujesz sshd:

semanage port -a -t ssh_port_t -p tcp 2222

Jeśli port jest już przypisany do innego typu, -a zakończy się informacją, że został on wcześniej zdefiniowany. Zmień wtedy przypisanie za pomocą -m, zamiast dodawać nowe.

Kontrola: semanage port -l | grep ssh_port_t wypisuje teraz oba porty. Jeśli mimo to coś się zacina, odrzucone dostępy pokaże:

ausearch -m avc -ts recent

Debian i Ubuntu w instalacji standardowej nie mają porównywalnego ograniczenia, tam ta sekcja odpada.

Częste błędy i ich rozwiązania

ssh: connect to host 203.0.113.10 port 2222: Connection refused: pakiety docierają, ale nikt nie nasłuchuje. Usługa nie została zrestartowana, konfiguracja nie doszła albo wiersz ListenAddress wiąże ją z innym adresem.

ssh: connect to host 203.0.113.10 port 2222: Connection timed out: pakiety w ogóle nie docierają, prawie zawsze przez filtr pakietów na serwerze albo w twojej własnej sieci. Różnica wobec poprzedniego komunikatu to najważniejsza informacja diagnostyczna w całym temacie: odrzucone znaczy brak usługi, przekroczony czas znaczy filtr.

error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.: na systemach RHEL to SELinux, patrz wyżej. Na Debianie i Ubuntu ten komunikat pojawia się praktycznie tylko wtedy, gdy sshd nie działa jako root, a ma zająć port poniżej 1024.

error: Bind to port 2222 on 0.0.0.0 failed: Address already in use.: port trzyma inny proces, a ss -tlnp | grep ':2222 ' go wskaże. Jeśli błąd występuje tylko sporadycznie po restarcie, port leży w zakresie dynamicznych portów źródłowych, patrz krok 1.

fatal: Cannot bind any address.: żadnego z żądanych adresów nie dało się zająć. Na Debianie i Ubuntu oznacza to z reguły, że port trzyma już ssh.socket, a ty chcesz uruchomić na nim dodatkowo ssh.service.

Job for ssh.service failed because the control process exited with error code.: przyczyna stoi w dzienniku, a nie w tym wierszu. Pokaże ją journalctl -u ssh -n 50 --no-pager, niezależnie od wersji OpenSSH.

/etc/ssh/sshd_config.d/20-port.conf line 1: Bad configuration option: prot: literówka. sshd -t poda plik i numer wiersza, dokładnie po to stoi to polecenie przed każdym restartem.

sshd: no hostkeys available -- exiting.: brakuje kluczy hosta albo nie da się ich odczytać, a ssh-keygen -A wygeneruje brakujące. sshd -t i sshd -T potrzebują do nich prawa odczytu i dlatego muszą działać jako root.

ssh: connect to host 203.0.113.10 port 22: Connection refused po udanej zmianie: twój klient nadal próbuje portu domyślnego. Uzupełnij ~/.ssh/config albo podaj -p.

Jeśli mimo wszystko zamknąłeś sobie dostęp

1. Nie restartuj serwera. Restart odtwarza reguły firewalla i konfigurację usługi, więc serwer wróci dokładnie tak samo zamknięty.
2. Otwórz konsolę VNC w panelu klienta i zaloguj się jako root. Logowanie przez konsolę nie idzie przez SSH i twoja zmiana go nie dotyczy.
3. Ustal klasę błędu. ss -tlnp odpowiada na to natychmiast: jeśli port tam jest, to problem z filtrem. Jeśli go nie ma, to problem z usługą, a journalctl -u ssh -n 50 --no-pager powie dlaczego.
4. Wycofaj zmianę zamiast naprawiać. rm -f /etc/ssh/sshd_config.d/20-port.conf i, jeśli plik powstał, rm -f /etc/systemd/system/ssh.socket.d/override.conf, potem systemctl daemon-reload i systemctl try-restart ssh.socket ssh.service.
5. Jeśli przyczyną był firewall, pomoże ufw disable, a po nim czysta odbudowa reguł z poprawnym otwarciem portu.

W skrócie

• Najpierw firewall, sshd dopiero potem. Stary port zostaje otwarty, dopóki nowy nie udowodni, że działa.
• Kilka wierszy Port sumuje się i to czyni przejście bezpiecznym. Wartość domyślna 22 odpada, gdy tylko pojawi się jakikolwiek wiersz Port.
• Przy aktywacji przez socket, fabrycznie na Ubuntu 24.04, port stoi w ListenStream.
• Rozstrzygający nie jest nigdy plik konfiguracyjny, tylko ss -tlnp przefiltrowany po numerze portu.
• Drogą ratunkową jest konsola VNC w panelu klienta, miej więc hasło roota pod ręką.

Jeśli dopiero uruchamiasz serwer, nasza lista kontrolna dla nowych serwerów root wpisuje ten krok w całą podstawową konfigurację. I jeszcze raz dla porządku: inny port sprawia, że twoje logi stają się czytelne. Bezpieczny dostęp daje dopiero logowanie kluczem i wyłączone logowanie hasłem. Jeśli wdrożysz tylko jedno z dwojga, wybierz to drugie.