SSH Connection refused a Connection timed out - różnice

Co oznaczają błędy "Connection refused" oraz "Connection timed out" w SSH

Błąd odmowy połączenia (Connection refused) oraz przekroczenie czasu oczekiwania (Connection timed out) to przeciwstawne awarie, dlatego rozwiązanie jednego problemu nigdy nie naprawi drugiego. Odmowa oznacza, że pakiet dotarł do serwera, a jądro systemu odpowiedziało: „nic tutaj nie nasłuchuje”. Przekroczenie czasu oznacza, że pakiet nie dotarł do nikogo, kto mógłby odpowiedzieć, więc klient czekał, aż w końcu zrezygnował. Odmowa to problem z usługą na serwerze. Przekroczenie czasu to problem z drogą dostępu przed serwerem.

Należy odczytać dokładny komunikat wyświetlony przez klienta, ponieważ jego treść stanowi pełną diagnozę.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

Czas reakcji jest drugą wskazówką. Odmowa pojawia się natychmiast, w czasie odpowiadającym jednemu cyklowi komunikacji (round trip). Przekroczenie czasu trwa wiele sekund przed wyświetleniem komunikatu, ponieważ klient ponawia próby transmisji przed rezygnacją. System macOS wyświetla Operation timed out dla tego samego stanu. Jeśli sam protokół jest nowością, jak działa SSH i co robi sshd stanowi podstawę wiedzy, na której opiera się ten przewodnik.

Dlaczego "Connection refused" to dobra wiadomość

Komunikat "Connection refused" oznacza reset protokołu TCP (transmission control protocol). Klient wysyła pakiet SYN na port 22. Pakiet dociera przez sieć do stosu sieciowego serwera, a jądro systemu nie znajduje gniazda nasłuchującego na tym porcie, więc odpowiada pakietem RST (reset). Klient SSH interpretuje ten pakiet RST jako komunikat Connection refused.

Ten jeden pakiet zwrotny dostarcza wielu informacji. Adres jest poprawny. Host jest włączony i obsługuje routing. Żaden element na ścieżce nie odrzuca ruchu w sposób cichy, ponieważ odpowiedź nadeszła z urządzenia docelowego. Wszystkie pozostałe przyczyny problemu znajdują się zatem na samym serwerze.

• sshd nie działa, ponieważ nie uruchomił się lub nie został włączony.
• sshd nasłuchuje na innym porcie, co zazwyczaj wynika z wprowadzenia zmian w zabezpieczeniach.
• sshd jest powiązany tylko z jednym adresem, takim jak ListenAddress 127.0.0.1, więc dostęp do niego ma wyłącznie sam serwer.
• Firewall jest skonfigurowany tak, aby odrzucać (reject) zamiast ignorować (drop) pakiety, więc wysyła RST w imieniu hosta. Działanie reject w ufw oraz reguła nftables kończąca się na reject with tcp reset powodują takie zachowanie.

Istnieje jeszcze jeden przypadek, który wygląda podobnie, ale nim nie jest: wprowadzono adres należący do innego aktywnego hosta. Ten host odpowiada na pakiet SYN, nie posiada usługi SSH na porcie 22 i grzecznie odmawia połączenia. Należy zweryfikować adres przed poświęceniem czasu na diagnozowanie niewłaściwego serwera. Zrozumienie czym w systemie Linux jest nasłuchujący port przyspiesza lekturę pozostałej części tej sekcji.

Jak naprawić błąd Connection refused

Naprawa przez SSH nie jest możliwa, ponieważ to właśnie usługa SSH uległa awarii. Należy otworzyć konsolę internetową lub szeregową dostawcy, zalogować się i wykonać poniższe polecenia.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh to nazwa jednostki w systemach Ubuntu i Debian. W systemach RHEL oraz ich pochodnych, takich jak AlmaLinux, jednostka nosi nazwę sshd. Polecenie ss -tlnp wyświetla wszystkie gniazda TCP w stanie nasłuchiwania wraz z przypisanymi do nich procesami; jest to ostateczne źródło informacji: jeśli na liście brakuje sshd, oznacza to, że usługa nie nasłuchuje, niezależnie od treści pliku konfiguracyjnego. Polecenie sshd -T wyświetla efektywną konfigurację po scaleniu wszystkich plików Include, co pozwala wykryć zapomniany port zdefiniowany w /etc/ssh/sshd_config.d/.

Należy uważnie przeanalizować kolumnę adresów. 0.0.0.0:22 oznacza wszystkie adresy IPv4 na serwerze. [::]:22 oznacza wszystkie adresy IPv6. 127.0.0.1:22 oznacza wyłącznie interfejs pętli zwrotnej (loopback), przez co każde zdalne połączenie jest odrzucane, podczas gdy lokalne ssh localhost działa poprawnie.

Jeśli usługa nie nasłuchuje, należy ją uruchomić i odczytać komunikat o błędzie, jeśli start zakończy się niepowodzeniem.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t analizuje konfigurację i wskazuje plik oraz numer linii zawierającej błędną dyrektywę, nie wpływając przy tym na działającą usługę. Polecenie to należy uruchamiać przed każdym restartem, ponieważ odrzucona konfiguracja powoduje natychmiastowe zakończenie pracy sshd, co skutkuje odrzuceniem kolejnych prób połączenia.

Pułapka aktywacji gniazda w Ubuntu

Ubuntu 24.04 dostarcza jednostkę gniazda systemd dla OpenSSH. Gdy ta jednostka jest włączona, systemd przejmuje port nasłuchiwania i uruchamia sshd dla każdego połączenia, więc Port 2222 w sshd_config nie zmienia niczego, a serwer nadal odpowiada na starym porcie. Przed przystąpieniem do edycji należy sprawdzić, w jakim trybie działa usługa.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

Jeśli gniazdo jest włączone, port należy ustawić w jednostce gniazda, a nie w sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Pusta linia ListenStream= jest wymagana, ponieważ ustawienia listy systemd są dodawane do już istniejącej konfiguracji. Pominięcie jej spowoduje, że serwer będzie nasłuchiwał na obu portach. Zastosuj zmianę za pomocą sudo systemctl daemon-reload oraz sudo systemctl restart ssh.socket, a następnie potwierdź za pomocą sudo ss -tlnp, że nowy port jest tym, który jest obecnie zajęty. Zmiana portu to standardowy krok w ramach utwardzania SSH na serwerze VPS i jest to czynność, która najczęściej skutkuje utratą dostępu do serwera.

Dlaczego "Connection timed out" oznacza brak odpowiedzi

Limit czasu (timeout) oznacza ciszę. Klient wysłał pakiet SYN, ponowił próbę kilkukrotnie w ciągu minuty lub dwóch i nie otrzymał w zamian żadnego pakietu. W tej sytuacji nie można wyciągnąć żadnych wniosków na temat serwera, ponieważ nie nadeszła z niego żadna odpowiedź.

Cisza jest dokładnie tym, co generuje reguła DROP, a odrzucanie pakietów (dropping) jest działaniem celowym. Odrzucenie (rejection) informuje skanującego, że host istnieje, dlatego ufw oraz każdy sieciowy firewall dostawcy chmury odrzucają niechciane pakiety i nie wysyłają nic w odpowiedzi. Timeout zazwyczaj oznacza, że firewall poprawnie wykonuje swoje zadanie na porcie, który miał być otwarty.

• Adres jest błędny: rekord DNS nadal wskazuje na serwer, który został przebudowany, lub wystąpiła literówka prowadząca na nieużywany adres.
• Host nie działa: jest wyłączony lub w trakcie restartu. Zawieszenie usługi przez dostawcę z powodu nieopłaconych faktur wygląda z zewnątrz identycznie.
• Firewall hosta odrzuca port 22, najczęściej dlatego, że ufw enable zostało uruchomione przed dodaniem jakiejkolwiek reguły zezwalającej.
• Firewall dostawcy znajdujący się przed instancją odrzuca ruch, przez co system operacyjny w ogóle nie otrzymuje pakietu.
• Własna sieć blokuje wychodzący port 22, co jest częstym zjawiskiem w sieciach biurowych i hotelowych.

Uruchomienie testu od strony połączenia

Oto błąd, który pochłania najwięcej czasu. Nie można zdiagnozować utraconego pakietu z wnętrza maszyny, do której pakiety nie docierają. Gdyby możliwe było zalogowanie się w celu uruchomienia polecenia, problem by nie istniał. Każde polecenie w tej sekcji należy uruchomić na własnej maszynie.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts wyświetla adres, którego faktycznie użyje maszyna, co pozwala w kilka sekund wykryć nieaktualny rekord DNS. ssh -G wypisuje ustawienia stosowane przez klienta po odczytaniu ~/.ssh/config, co pozwala wykryć stary blok Host, który po cichu nadpisuje nazwę hosta, port lub użytkownika. ssh -vvv pokazuje, jak daleko dotarła próba połączenia: ostatnia linia dotycząca łączenia się z adresem, po której następuje długa pauza, oznacza przekroczenie limitu czasu (timeout), natomiast linia informująca o wersji zdalnego OpenSSH oznacza, że połączenie TCP zakończyło się sukcesem, a rzeczywisty problem dotyczy uwierzytelniania. W systemie Windows polecenie Test-NetConnection 203.0.113.10 -Port 22 w PowerShell zastępuje nc.

Należy testować port, a nie hosta. Nieudane ping niczego nie dowodzi, ponieważ wielu dostawców filtruje ICMP (internet control message protocol) na brzegu sieci. Udany ping również niczego nie dowodzi, ponieważ nie dostarcza informacji o porcie 22.

Następnie należy zmienić jedyną zmienną, której nie zmieni za użytkownika żadne polecenie: sieć. Należy ponowić próbę, korzystając z hotspotu w telefonie. Jeśli połączenie przez hotspot działa, a połączenie z biurka nie, blokada znajduje się po stronie użytkownika lub adres biurowy został zablokowany na serwerze.

Zapora sieciowa dostawcy niewidoczna z poziomu serwera

Większość paneli VPS oferuje sieciową zaporę ogniową, nazywaną czasem grupą zabezpieczeń lub zaporą chmurową, która działa przed instancją i posiada własną listę reguł. ufw status na serwerze nie widzi tych ustawień, dlatego stwierdzenie „przecież odblokowałem port 22” jest tak częste. Przed modyfikacją jakiejkolwiek reguły w systemie należy otworzyć panel zarządzania i sprawdzić tę listę.

Jedno polecenie rozstrzyga tę kwestię, lecz wymaga dostępu przez konsolę. Należy uruchomić je na serwerze, a następnie spróbować nawiązać połączenie z laptopa w trakcie jego działania.

sudo tcpdump -ni any tcp port 22

Jeśli w trakcie próby połączenia klienta nic się nie pojawia, pakiety są odrzucane, zanim dotrą do systemu operacyjnego. W takim przypadku przyczyną jest zapora dostawcy lub trasa do hosta. Jeśli pakiety SYN docierają, ale brak odpowiedzi, odrzucenie następuje lokalnie i dotyczy ufw lub nftables. Ten pojedynczy test dzieli problem braku odpowiedzi na pół, dlatego warto skorzystać z dostępu do konsoli.

Kolejność reguł ufw, IPv6 oraz samodzielne zablokowanie dostępu

Błąd w kolejności reguł ufw jest najczęstszą przyczyną utraty dostępu do serwera. sudo ufw enable natychmiast stosuje domyślną politykę odrzucania ruchu przychodzącego, więc bez wcześniejszego zdefiniowania reguły dla SSH, bieżąca sesja pozostanie aktywna dzięki istniejącemu połączeniu, ale każde nowe połączenie zostanie odrzucone. Najpierw zezwól na dostęp, a dopiero potem włącz zaporę.

sudo ufw allow OpenSSH
sudo ufw status verbose

Profil aplikacji OpenSSH obejmuje wyłącznie port 22. Jeśli planujesz przenieść SSH na port 2222, niezbędna reguła to sudo ufw allow 2222/tcp, którą należy dodać przed zmianą portu, a nie po niej. Szerszy zestaw reguł opisano w podstawach zapory ufw dla VPS, a bezpieczna kolejność działań jest częścią pierwszych kroków na nowym VPS.

IPv6 powoduje timeouty, które mogą wydawać się niezrozumiałe. Jeśli nazwa hosta posiada rekord AAAA, klient najpierw podejmie próbę połączenia przez IPv6. W rezultacie serwer, który nie posiada reguł dla IPv6, zawiesi połączenie, podczas gdy próba przez IPv4 zadziała poprawnie. Należy skonfigurować oba protokoły oddzielnie.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

Jeśli -4 łączy się, a -6 nie, rozwiązanie leży w regułach IPv6 na serwerze. Procedurę otwierania tego samego portu dla IPv6 w ufw opisano w osobnym poradniku.

Możliwe jest również samodzielne zablokowanie dostępu. fail2ban monitoruje logi uwierzytelniania i dodaje reguły zapory dla adresów, z których pochodzi zbyt wiele nieudanych prób logowania. Błędny klucz lub skrypt działający w tle może zablokować cały adres IP biura. Blokada typu drop wygląda jak timeout. Blokada typu reject zwraca komunikat No route to host. Z poziomu konsoli:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Dodanie własnego adresu do ignoreip jest częścią poprawnej konfiguracji fail2ban na Ubuntu 24.04.

Błędy, które nie są odrzuceniem ani przekroczeniem czasu oczekiwania

No route to host oznacza, że otrzymano komunikat ICMP o nieosiągalności. Twoja maszyna nie posiada trasy do tej sieci lub urządzenie na ścieżce zwróciło administracyjną odmowę, co jest działaniem reguły REJECT w iptables.

Network is unreachable oznacza komunikat generowany przez Twoją maszynę. Nie posiada ona trasy dla tej rodziny adresów; jest to typowa odpowiedź, gdy nazwa hosta rozwiązuje się tylko do adresu IPv6 w połączeniu obsługującym wyłącznie IPv4.

kex_exchange_identification: Connection closed by remote host oznacza, że połączenie TCP zostało nawiązane, a serwer rozłączył się przed zakończeniem wymiany kluczy. Port jest otwarty, a sshd działa, więc należy sprawdzić obciążenie serwera, MaxStartups lub blokadę, która została nałożona w trakcie nawiązywania połączenia.

Permission denied (publickey) oznacza, że proces dotarł do etapu uwierzytelniania i zakończył się niepowodzeniem. Sieć i firewall działają poprawnie, więc wskazówki z tego przewodnika nie mają zastosowania. Przejdź do naprawy błędu Permission denied (publickey) w SSH.

Jak odzyskać dostęp i uniknąć ponownej blokady

Każdy poważny dostawca VPS udostępnia konsolę niezależną od sieci gościa: konsolę szeregową lub ekran VNC dostępny przez przeglądarkę. Konsola ta stanowi drogę ratunkową dla obu ścieżek opisanych w tym przewodniku, ponieważ działa nawet wtedy, gdy usługa sshd jest zatrzymana lub reguła zapory sieciowej odrzuca cały ruch. Należy ją odnaleźć w panelu zarządzania, zalogować się jako root lub użytkownik standardowy, a następnie wykonać powyższe testy. Jeśli hasło dla konta root nie zostało ustawione, większość paneli umożliwia jego zresetowanie.

W przypadku braku konsoli, rozwiązaniem awaryjnym jest tryb ratunkowy (rescue mode) oferowany przez dostawcę. Uruchamia on niewielki system odzyskiwania i montuje dysk, co pozwala na edycję /etc/ssh/sshd_config lub usunięcie reguły zapory w trybie offline, a następnie ponowne uruchomienie serwera.

Dwa nawyki pozwalają uniknąć kolejnej blokady. Podczas edycji sshd lub zapory sieciowej należy zawsze utrzymywać otwartą drugą sesję SSH, ponieważ przetrwa ona dzięki ustanowionemu stanowi połączenia, podczas gdy testowana będzie nowa konfiguracja. Warto również zapewnić sobie automatyczne wycofanie zmian przed wprowadzeniem ryzykownej modyfikacji zapory.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

Pierwsza linia planuje wyłączenie ufw po upływie dziesięciu minut. Należy zastosować nowe reguły, otworzyć nową sesję SSH w celu weryfikacji ich działania, a następnie wykonać drugą linię, aby anulować wycofanie zmian. W przypadku zablokowania dostępu należy odczekać dziesięć minut, aż zapora wyłączy się samoczynnie. Pozostawia to serwer bez filtrowania do momentu ponownego włączenia ufw, dlatego rozwiązanie to należy stosować wyłącznie podczas pracy przy klawiaturze, a nie jako konfigurację stałą.

Kolejność działań

1. Przeczytaj treść błędu i zwróć uwagę na czas, po którym wystąpił.
2. Refused: przejdź do konsoli i sprawdź za pomocą sudo ss -tlnp, czy gniazdo nasłuchuje, na jakim porcie oraz pod jakim adresem.
3. Timed out: potwierdź poprawność adresu ze swojej maszyny, a następnie sprawdź zaporę sieciową dostawcy w panelu oraz lokalną zaporę na serwerze.
4. Brak powyższych komunikatów: połączenie TCP zostało nawiązane, więc problem dotyczy uwierzytelniania lub obciążenia serwera, a nie sieci.

FAQ

Dlaczego SSH zwraca "Connection refused", mimo że sshd działa?

Ponieważ odmowa pochodzi z gniazda, a nie z samej usługi, a działający proces sshd nadal może odrzucić połączenie. Otwórz konsolę dostawcy i wykonaj sudo ss -tlnp. Gniazdo na 127.0.0.1:22 odrzuca każdego zdalnego klienta, ponieważ jest powiązane wyłącznie z interfejsem loopback. Gniazdo na innym porcie odrzuci każdego, kto nadal korzysta z portu 22. Jeśli używana jest aktywacja gniazd systemd, port jest definiowany w ssh.socket, a nie w sshd_config, więc sprawdź również systemctl is-enabled ssh.socket. Reguła ufw reject również zwraca odmowę w imieniu hosta, dlatego przed wyciągnięciem wniosków przeczytaj sudo ufw status verbose.

Dlaczego połączenie SSH przekracza czas oczekiwania, skoro ufw zezwala na port 22?

Ponieważ przekroczenie czasu oczekiwania oznacza brak odpowiedzi, a ufw nie jest jedyną zaporą sieciową na ścieżce pakietów. Większość paneli VPS uruchamia sieciowy firewall przed instancją, a system operacyjny nigdy nie widzi pakietów, które ten firewall odrzuca. Z poziomu konsoli wykonaj sudo tcpdump -ni any tcp port 22 i spróbuj połączyć się z laptopa w trakcie działania polecenia. Brak docierających pakietów oznacza, że odrzucenie następuje na poziomie infrastruktury dostawcy. Pakiety docierające, przy braku odpowiedzi wychodzącej, oznaczają odrzucenie lokalne w ufw lub nftables.

Czy nieudany ping oznacza, że mój VPS nie działa?

Nie. Wielu dostawców filtruje ICMP na brzegu sieci, więc serwer obsługujący ruch może ignorować każdy wysłany ping. Udany ping jest równie mało miarodajny w drugą stronę, ponieważ nie informuje o tym, czy port 22 jest otwarty. Przetestuj sam port za pomocą nc -vz -w 5 203.0.113.10 22 z własnej maszyny lub za pomocą Test-NetConnection 203.0.113.10 -Port 22 w PowerShell na systemie Windows.

Zmieniłem port SSH i teraz nic się nie łączy. Co poszło nie tak?

Dwie przyczyny najczęściej powodują ten problem. Jeśli firewall nie otrzymał reguły dla nowego portu, próby połączenia z nowym portem przekraczają czas oczekiwania, podczas gdy port 22 zwraca odmowę, dlatego sudo ufw allow 2222/tcp należy wykonać przed zmianą portu, a nie po niej. Jeśli serwer używa aktywacji gniazd systemd dla SSH, Port 2222 w sshd_config jest ignorowane, a systemd nadal utrzymuje stary port, co można potwierdzić za pomocą systemctl is-enabled ssh.socket. Odzyskaj dostęp przez konsolę dostawcy, napraw odpowiedni element, a następnie połącz się za pomocą ssh -p 2222 user@203.0.113.10, gdy sudo ss -tlnp pokaże nowe gniazdo.