Jak odblokować SSH po błędnej konfiguracji ufw

Odzyskiwanie dostępu

Jeśli ufw zablokowało dostęp do VPS, jedyną drogą powrotną jest konsola dostawcy lub tryb ratunkowy, ponieważ po aktywacji reguły blokującej nie istnieje rozwiązanie oparte na SSH. Jądro odrzuca pakiety, zanim sshd je otrzyma, więc nie ma możliwości zalogowania się ani naprawy przez sieć. Należy otworzyć konsolę w panelu sterowania dostawcy, zalogować się w wierszu poleceń i wykonać jedno polecenie.

sudo ufw disable

Powinien pojawić się komunikat Firewall stopped and disabled on system startup. Nowe połączenia SSH zaczną działać w ciągu sekundy lub dwóch. Żadna konfiguracja nie zostanie utracona: disable usuwa reguły z jądra i zapisuje ENABLED=no w /etc/ufw/ufw.conf, podczas gdy reguły użytkownika pozostają na dysku w /etc/ufw/user.rules, oczekując na kolejne ufw enable.

Nie należy restartować serwera w nadziei na rozwiązanie problemu. ufw uruchamia się automatycznie podczas startu systemu, więc ENABLED=yes oznacza, że ten sam zestaw reguł zostanie załadowany ponownie, zanim sieć będzie gotowa. Restart nie zmienia nic w kwestii blokady nałożonej przez ufw.

Konsola wymaga hasła, którego możesz nie posiadać

Konsola internetowa (VNC lub szeregowa) jest odpowiednikiem klawiatury podłączonej bezpośrednio do maszyny. Nie jest to ścieżka sieciowa, więc żadna reguła firewalla nie może jej zablokować. Wymaga ona jednak lokalnego logowania, co stanowi problem w konfiguracjach opartych wyłącznie na kluczach SSH: jeśli hasło użytkownika sudo nie zostało ustawione, a logowanie na root jest zablokowane, konsola wyświetli monit, na który nie można odpowiedzieć. Ustaw to hasło teraz, dopóki masz dostęp przez SSH: sudo passwd yourname. Większość paneli pozwala również na zresetowanie hasła root, co zazwyczaj wymusza restart systemu.

Jeśli konsola jest bezużyteczna, uruchom system ratunkowy dostawcy. Działa on jako oddzielny system operacyjny z niezamontowanym dyskiem, co pozwala na wyłączenie ufw z zewnątrz.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Najpierw uruchom lsblk, ponieważ partycja root nie zawsze jest /dev/vda1. Po restarcie do normalnego systemu ufw pozostanie wyłączony, dopóki nie włączysz go ręcznie.

Minimalna procedura odzyskiwania

Należy postępować zgodnie z poniższą kolejnością. Pierwsze cztery kroki są bezpieczne. Kolejny krok niesie ryzyko.

1. sudo ufw disable, aby wyładować reguły i odzyskać dostęp.
2. sudo ufw show added, aby wyświetlić dodane reguły w formie poleceń, które je utworzyły. Działa to, gdy ufw jest nieaktywne, w przeciwieństwie do ufw status.
3. sudo sshd -T | grep -i '^port', aby potwierdzić port, na którym faktycznie nasłuchuje sshd. Wyświetla on port 22, chyba że port został zmieniony.
4. sudo ufw allow 22/tcp, używając właściwego portu, aby kolejne włączenie nie spowodowało ponownego zablokowania dostępu.
5. sudo ufw enable, z uprzednio zaplanowanym wycofaniem zmian. Szczegóły znajdują się w dalszej części tej strony.

Co faktycznie robi ufw reset

ufw reset to ostateczność, a nie pierwszy krok. Polecenie to wyłącza zaporę, tworzy kopię zapasową wszystkich plików reguł i przywraca domyślne ustawienia: blokowanie ruchu przychodzącego i zezwalanie na wychodzący. Wyświetla jedną linię kopii zapasowej dla każdego pliku:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Po resecie nie istnieją żadne reguły zezwalające, dlatego polecenie należy wykonać z poziomu konsoli, a nie przez SSH. Przed ponownym włączeniem zapory należy dodać regułę dla SSH. Kopie zapasowe są plikami tekstowymi. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 pokazuje, jakie były poprzednie reguły, co pozwala na odtworzenie zestawu reguł, którego nie zamierzano usunąć.

Gdzie ufw przechowuje swoje reguły

Analiza plików jest skuteczniejsza niż poleganie na pamięci. Cały stan konfiguracji znajduje się w pięciu ścieżkach:

• /etc/ufw/user.rules oraz /etc/ufw/user6.rules: reguły dodane przez użytkownika, w kolejności ich sprawdzania.
• /etc/ufw/before.rules oraz /etc/ufw/after.rules, wraz z wariantami 6: szkielet, który ufw nakłada na reguły użytkownika, w tym akceptację nawiązanych połączeń oraz reguły dla interfejsu loopback.
• /etc/default/ufw: domyślne polityki oraz przełącznik IPV6.
• /etc/ufw/ufw.conf: ENABLED oraz poziom logowania.
• /var/log/ufw.log: historia zablokowanych zdarzeń, jeśli logowanie jest aktywne.

Przed nadpisaniem pliku ufw tworzy jego kopię z sygnaturą czasową, dlatego ls /etc/ufw/ zapełnia się nazwami takimi jak user.rules.20260813_101500. Jest to historia zmian, którą warto przejrzeć przed ręcznym przywracaniem poprzednich ustawień.

Aby sprawdzić reguły załadowane do jądra, zamiast tych zapisanych na dysku, należy użyć sudo ufw show raw lub sudo iptables -S i sudo ip6tables -S. W systemach Ubuntu 22.04 oraz 24.04 polecenia te korzystają z backendu nft, więc sudo nft list ruleset wyświetla te same reguły w nowszej składni.

Dlaczego włączenie ufw przerwało moją sesję SSH?

Domyślna polityka dla ruchu przychodzącego to deny. Włączenie ufw bez reguły zezwalającej na port SSH odcina każde nowe połączenie. Narzędzie ufw wyświetla ostrzeżenie: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Odpowiedź y bez wcześniejszego dodania reguły zezwalającej na SSH jest najczęstszą przyczyną problemów opisanych na tej stronie.

Kłopotliwe jest opóźnienie w działaniu. /etc/ufw/before.rules akceptuje pakiety w stanie ESTABLISHED,RELATED zanim zostaną przetworzone własne reguły, więc sesja, w której wprowadzono polecenie, działa nadal poprawnie. Blokada występuje dopiero przy kolejnej próbie połączenia, co może nastąpić nawet po kilku godzinach, przez co zmiana w zaporze nie jest kojarzona z tym zdarzeniem. Zawsze otwieraj drugą sesję SSH i potwierdzaj jej działanie przed zamknięciem pierwszej.

Dlaczego apt i DNS przestały działać po zmianie polityki?

sudo ufw default deny outgoing blokuje wychodzące zapytania DNS (domain name system) oraz ruch HTTP, przez co rozwiązywanie nazw przestaje działać, a aktualizacje pakietów są przerywane. apt update zgłasza Temporary failure resolving 'archive.ubuntu.com'. Przychodzące połączenia SSH nadal działają, ponieważ odpowiedzi na nie są oznaczane jako ESTABLISHED i przechodzą przez reguły frameworka, co sprawia, że firewall wydaje się poprawny, mimo że to on jest przyczyną problemu.

Jeśli wymagana jest polityka blokująca ruch wychodzący, należy odblokować zasoby niezbędne dla maszyny:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Bez ostatniej reguły zegar systemowy ulega rozsynchronizowaniu, a błędny czas uniemożliwia weryfikację certyfikatów TLS (transport layer security), przez co curl zaczyna zgłaszać błędy daty, a nie problemy z portami. Ten objaw pojawia się kilka dni po wprowadzeniu zmian, dlatego polityka blokowania ruchu wychodzącego jest przeznaczona dla maszyn monitorowanych, a nie dla systemów konfigurowanych jednorazowo.

Dlaczego reguła ufw nie jest dopasowywana?

Narzędzie ufw ocenia reguły użytkownika w kolejności występowania i zatrzymuje się na pierwszym dopasowaniu. Reguła deny dodana po ogólnej regule allow nigdy nie zostanie użyta, ponieważ zezwolenie zostało już przyznane na podstawie wcześniejszego wpisu. Należy wyświetlić kolejność reguł z numerami, a następnie wstawić nową regułę w odpowiednim miejscu.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

Polecenie sudo ufw --dry-run allow 8080/tcp wyświetla reguły, które zostałyby zapisane, nie wprowadzając żadnych zmian. Jest to bezpieczny sposób na sprawdzenie reguły przed jej wdrożeniem.

Kolejną pułapką są profile aplikacji. Polecenie sudo ufw allow OpenSSH korzysta z profilu w /etc/ufw/applications.d/openssh-server, który domyślnie odnosi się do portu 22. Jeśli sshd nasłuchuje na porcie 2222, reguła otwiera port, z którego nikt nie korzysta, co skutkuje zablokowaniem dostępu przy pozornie poprawnej konfiguracji. Po zmianie portu należy używać numeru portu w regule. Pozostała część składni została opisana w podstawach zapory sieciowej ufw dla VPS.

Dlaczego reguły IPv4 nie wyjaśniają tego, co widzę?

Ponieważ połowa ruchu nie jest obsługiwana przez IPv4. Ubuntu dostarcza IPV6=yes w /etc/default/ufw, a ufw utrzymuje równoległy zestaw reguł v6 w /etc/ufw/user6.rules. Reguła zapisana z adresem IPv4, taka jak ufw allow from 203.0.113.10 to any port 22, nie tworzy żadnej reguły v6. Jeśli VPS posiada rekord AAAA, klient preferuje IPv6, a połączenie kończy się przekroczeniem czasu oczekiwania, podczas gdy ufw status pokazuje regułę, która wygląda na poprawną. Należy przetestować różnicę za pomocą ssh -4 user@host względem ssh -6 user@host. Jeśli pierwsze polecenie działa, a drugie nie, luką jest zestaw reguł v6.

Odwrotny przypadek jest gorszy dla bezpieczeństwa. Przy IPV6=no, ufw w ogóle nie zarządza ip6tables, więc polityka v6 pozostaje na domyślnym poziomie jądra ACCEPT. Port, który uznawany jest za zamknięty, odpowiada na swoim adresie IPv6, a żadne polecenie ufw nigdy o nim nie wspomni. Należy sprawdzić to za pomocą sudo ip6tables -S oraz ss -tlnp i przeczytać jak ufw obsługuje porty IPv6, aby uzyskać pełny obraz sytuacji.

Dlaczego port Docker jest otwarty, mimo że ufw go blokuje?

Docker publikuje port poprzez zapisanie reguł DNAT (destination network address translation) w tablicy nat oraz wstawienie własnego łańcucha do FORWARD. Reguły ufw znajdują się w ścieżce INPUT. Ruch kierowany do kontenera jest przekazywany (forwarded), a nie dostarczany bezpośrednio do hosta, więc nigdy nie dociera do łańcucha, w którym znajduje się reguła blokująca. docker run -p 5432:5432 jest dostępny z Internetu, nawet gdy ufw jest aktywne i blokuje cały ruch.

sudo iptables -t nat -S DOCKER

Najprostszym rozwiązaniem jest publikacja na interfejsie loopback: -p 127.0.0.1:5432:5432 wiąże stronę hosta z 127.0.0.1, dzięki czemu żaden podmiot zewnętrzny nie uzyska dostępu, niezależnie od konfiguracji ufw. Publikowanie portów Docker z pominięciem ufw omawia przypadki, w których usługa musi być publicznie dostępna.

Zaplanuj wycofanie zmian przed zastosowaniem reguły

Jest to nawyk, który umożliwia bezpieczną pracę z firewallem. Przed wprowadzeniem ryzykownej zmiany zaplanuj jej wycofanie. Jeśli zmiana spowoduje utratę dostępu, maszyna przywróci stan pierwotny w ciągu 5 minut, co pozwoli uniknąć konieczności otwierania konsoli.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd wyświetli Running timer as unit: ufw-rollback.timer. Teraz wprowadź zmianę. Jeśli po jej wykonaniu nadal można otworzyć nową sesję SSH, anuluj wycofanie zmian:

sudo systemctl stop ufw-rollback.timer

Jeśli nie można otworzyć sesji, należy poczekać. ufw wyłączy się automatycznie, a kolejna próba połączenia zakończy się sukcesem. Klasyczna sztuczka shutdown -r +5 nie pomaga w przypadku ufw, ponieważ ufw ładuje ten sam zestaw reguł ponownie podczas startu systemu.

Utrzymanie alternatywnej metody dostępu

• Zaloguj się do konsoli dostawcy przed wystąpieniem awarii i potwierdź poprawność hasła. Konsola, której nigdy nie przetestowano, nie stanowi kopii zapasowej.
• Utwórz drugiego użytkownika z uprawnieniami sudo i własnym kluczem, aby uszkodzenie pliku authorized_keys nie oznaczało utraty dostępu.
• Sprawdź, czy dostawca oferuje sieciowy firewall w panelu zarządzania, niezależny od ufw. Blokuje on te same porty, a ufw status nie wyświetli informacji o jego działaniu.
• Nie ustawiaj ufw allow from <your home address> jako jedynej reguły SSH, jeśli adres ten jest dynamiczny. Dostawca może go zmienić w dowolnym momencie, co spowoduje utratę połączenia.

Najlepszym momentem na wykonanie tych czynności jest konfiguracja nowego serwera, równolegle z innymi zadaniami opisanymi w pierwsze dziesięć minut na nowym VPS.

Odmowa połączenia lub przekroczenie czasu oczekiwania wskazują na warstwę, w której wystąpił błąd

Connection refused oznacza, że pakiet dotarł do serwera, a system odesłał komunikat TCP reset. Ścieżka sieciowa jest poprawna, więc usługa sshd jest zatrzymana lub nasłuchuje na innym porcie. Firewall rzadko jest przyczyną, ponieważ ufw domyślnie odrzuca pakiety (drop), zamiast je odsyłać (reject).

Connection timed out oznacza, że nie otrzymano żadnej odpowiedzi. Jest to sygnatura odrzucenia pakietu (drop): przez ufw, firewall sieciowy dostawcy lub błędny adres. Poprawna interpretacja tych dwóch błędów pozwala zaoszczędzić godzinę domysłów, a różnica między odmową połączenia a przekroczeniem czasu oczekiwania omawia pozostałe przypadki.

Włącz logowanie przed wprowadzeniem kolejnej zmiany

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Zablokowany pakiet wygląda następująco:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 z własnym adresem w SRC= stanowi dowód na to, że to ufw blokuje połączenie, a nie sieć czy sshd. W obrazach minimalnych bez rsyslog plik /var/log/ufw.log nie istnieje, a te same wpisy pochodzą z sudo journalctl -k | grep UFW. ufw stosuje limitowanie szybkości dla własnych reguł logowania, więc brak wpisu nie jest dowodem na to, że pakiet został przepuszczony.

W przypadku wykrycia nieautoryzowanych reguł

Zestaw reguł, który uległ samoistnej zmianie, nie stanowi problemu z firewallem. Został on zmodyfikowany przez użytkownika z uprawnieniami root. Należy wykonać sudo grep ufw /var/log/auth.log, aby sprawdzić, jakie polecenia sudo zostały uruchomione i na jakim koncie, a następnie last, aby zweryfikować logowania w czasie wystąpienia zdarzenia. Jeśli konta nie należą do znanych użytkowników, należy przerwać debugowanie firewalla i zamiast tego wykonać procedurę dla przejętego serwera VPS. Ponowne włączenie firewalla na serwerze kontrolowanym przez osobę trzecią jedynie maskuje problem.

Przywracanie konfiguracji

Po ustaleniu przyczyny należy ponownie włączyć ufw w sposób eliminujący ryzyko utraty dostępu. Należy zezwolić na ruch na właściwym porcie SSH, zaplanować wycofanie zmian, włączyć zaporę, a następnie otworzyć nową sesję SSH w innym terminalu i zweryfikować poprawność połączenia. Dopiero po potwierdzeniu działania nowej sesji można zamknąć bieżącą. Warto pozostawić włączone logowanie na dobę, ponieważ dziennik pozwala zidentyfikować brakujące reguły znacznie szybciej niż analiza user.rules.

FAQ

Czy ufw disable usuwa moje reguły?

Nie. disable usuwa zestaw reguł z jądra i zapisuje ENABLED=no w /etc/ufw/ufw.conf. Reguły pozostają w /etc/ufw/user.rules oraz /etc/ufw/user6.rules, a sudo ufw show added wyświetla je, gdy firewall jest nieaktywny. ufw reset to polecenie, które czyści reguły, wykonując wcześniej kopię zapasową każdego pliku i wyświetlając wiersz w formacie Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Czy restart VPS cofnie blokadę ufw?

Nie. ufw uruchamia się podczas startu systemu z ENABLED=yes w /etc/ufw/ufw.conf, więc te same reguły są ładowane przed nawiązaniem połączenia sieciowego i blokada pozostaje aktywna. Restart pomaga tylko wtedy, gdy wcześniej wyłączono ufw lub po edycji pliku w trybie ratunkowym z zamontowanym dyskiem. Należy skorzystać z konsoli dostawcy i wykonać tam sudo ufw disable.

Dlaczego kontener Docker jest dostępny, mimo że ufw blokuje port?

Docker tworzy własne reguły DNAT i FORWARD dla każdego opublikowanego portu. Ruch ten jest przekazywany do kontenera, zamiast trafiać do hosta, więc nie przechodzi przez łańcuch INPUT, w którym znajduje się reguła deny programu ufw. Należy publikować porty na interfejsie loopback za pomocą -p 127.0.0.1:5432:5432, jeśli port ma być dostępny tylko dla hosta, oraz sprawdzić reguły zainstalowane przez Docker za pomocą sudo iptables -t nat -S DOCKER.

Nie mam hasła do konsoli ani trybu ratunkowego. Jakie mam opcje?

Pozostałe opcje zależą od dostawcy: reset hasła z poziomu panelu sterowania, który zazwyczaj restartuje serwer, lub podłączenie dysku do innej instancji w celu edycji /etc/ufw/ufw.conf. Przed ponowną instalacją serwera należy skontaktować się z pomocą techniczną, ponieważ reinstalacja usuwa wszystkie dane. Po odzyskaniu dostępu należy wykonać sudo passwd yourname i przetestować logowanie przez konsolę, aby kolejna blokada nie wymagała długotrwałej naprawy.