Problemy z SSH na VPS Ubuntu: sprawdź przyczynę błędu

Zbierz informacje z nowego połączenia

Polecenia klienta uruchamiaj na swoim komputerze z Linux, macOS albo WSL. Polecenia serwera wykonuj w działającej sesji lub konsoli. Zastąp przykładowy adres 203.0.113.10, konto ubuntu, port 22 i ścieżkę klucza własnymi wartościami.

Odczytaj konfigurację klienta i wykonaj świeże połączenie z wyłączonym współdzieleniem sesji. Przy pierwszym połączeniu zweryfikuj klucz hosta niezależnym, zaufanym kanałem.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Sprawdź wynikowe HostName, User, Port, IdentityFile oraz ustawienia proxy. Zapisz czas i pełny końcowy błąd. Log diagnostyczny może ujawniać adresy i nazwy kont; usuń dane poufne przed udostępnieniem. Nigdy nie wysyłaj klucza prywatnego.

Rozpoznaj etap błędu

Przesuń tabelę, aby zobaczyć pozostałe kolumny →

Jeśli log zawiera Connection established, późniejszy timeout nie oznacza, że wszystkie pakiety od początku blokowała zapora. Czytaj kolejność zdarzeń, nie tylko ostatnią linię.

Dla timeout sprawdź drogę do maszyny

Porównaj adres w panelu z adresem użytym przez ssh -v. Sprawdź DNS, stary rekord IPv6, VPN i host pośredniczący. Potwierdź, że VM działa, ma właściwą trasę i adres publiczny.

Reguła dopuszczająca SSH z jednego IPv4 /32 musi wskazywać obecny publiczny adres Twojego komputera. Po zmianie łącza stary adres przestaje pasować. Zapora dostawcy i zapora systemu gościa to osobne warstwy.

W Oracle sprawdź listy zabezpieczeń, NSG i routing oraz reguły obrazu przez konsolę. Nie czyść iptables i nie dodawaj UFW bez sprawdzenia instrukcji obrazu. Brak odpowiedzi na ping nie dowodzi niedostępności SSH.

Dla odmowy sprawdź nasłuch przez konsolę

Connection refused nie potwierdza, że trafiłeś na właściwy VPS. Zweryfikuj adres i port przed zmianami. Na docelowym serwerze odczytaj stan SSH, porty i poprawność konfiguracji.

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Przy aktywacji przez socket usługa ssh może być nieaktywna, podczas gdy ssh.socket prawidłowo nasłuchuje. Nie traktuj pojedynczego statusu jako powodu do restartu.

sshd -t sprawdza konfigurację oraz dostępność kluczy hosta, ale nie potwierdza osiągalności z Internetu. Zanim zastosujesz zmianę, zachowaj drugi sposób dostępu i ustal, czy portem zarządza socket.

Dla odrzuconego klucza sprawdź właściwe konto

Użyj konta podanego dla konkretnego obrazu. Nie zakładaj, że konto root albo ubuntu istnieje na każdym VPS. Najpierw sprawdź czytelność własnego klucza, jego odcisk i wybór tożsamości przez klienta.

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Opcja IdentitiesOnly ogranicza oferowane tożsamości, ale dodatkowe IdentityFile mogą pochodzić z konfiguracji. Sprawdź ssh -G. Jeśli klient nie może odczytać pliku klucza, najpierw popraw lokalną ścieżkę i uprawnienia.

Przez konsolę serwera sprawdź rzeczywisty katalog domowy konta, plik kluczy i prawa dostępu.

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Uwzględnij AuthorizedKeysFile, dołączone pliki, bloki Match oraz mechanizm kluczy dostawcy. Zachowaj istniejące poprawne klucze. Nie wyłączaj StrictModes i nie włączaj hasła jako przypadkowego obejścia diagnozy.

Zmieniony klucz hosta zweryfikuj niezależnie

Powodem może być przebudowa VM, ponowne użycie adresu albo podszycie się pod serwer. Potwierdź identyfikator maszyny i zaplanowaną zmianę, a następnie odczytaj odciski kluczy hosta w zaufanej konsoli systemu gościa.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Porównuj SHA256 dla tego samego algorytmu z odciskiem pokazanym przez klienta. Klucz z authorized_keys identyfikuje użytkownika; klucz punktu dostępowego konsoli Oracle również nie jest kluczem SSH docelowej VM.

Po potwierdzeniu zrób kopię known_hosts i zmień tylko wpis dla danego hosta oraz portu. Nie usuwaj całego pliku ani nie wyłączaj kontroli klucza hosta. Niewyjaśniona różnica oznacza, że nie należy kontynuować logowania.

Zastosuj jedną poprawkę i sprawdź nowe logowanie

Zmień tylko potwierdzoną przyczynę: konkretny adres źródłowy, port, konto, ścieżkę lub klucz. Przed zastosowaniem konfiguracji sprawdź składnię. Zmiana portu może wymagać uwzględnienia ssh.socket.

Otwórz nowe połączenie z wyłączonym współdzieleniem i sprawdź sudo, jeśli konto ma go używać. Stara sesja nie potwierdza, że nowe logowania działają. Dopiero po udanym teście zamknij dostęp awaryjny, którego już nie potrzebujesz.

Zapisz przyczynę i poprawkę. Kontynuuj konfigurację strony HTTPS, a przed kolejną większą zmianą przygotuj kopię i próbę odtworzenia.

Pytania i odpowiedzi