Jak řešit problémy s SSH na Ubuntu VPS

Zachovejte přístup a zaznamenejte jedno selhání

Nezavírejte fungující relaci a najděte záchrannou konzoli poskytovatele. Lokální příkazy patří do Linuxu, macOS nebo WSL na vašem počítači, serverové do existujícího SSH nebo ověřené konzole.

Dokumentační IP 203.0.113.10, účet ubuntu, port 22 a cestu klíče nahraďte skutečnými hodnotami. Nejprve zobrazte vyhodnocená nastavení klienta a poté proveďte jeden čerstvý pokus:

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

Prohlédněte hostname, user, port, identityfile a proxy. Druhý příkaz vypíná sdílení existujícího spojení. Uložte čas a konečnou chybu. Nový host key ověřte podle části níže. Před sdílením logu skryjte účty, adresy a cesty; soukromý klíč nesdílejte.

Vyberte správnou větev podle zprávy

Tabulku lze posouvat vodorovně.

Zpráva zužuje oblast hledání, nedokazuje jedinou příčinu. Pokud se timeout objevil až po Connection established, prověřte handshake a serverové logy, nikoli jen předpoklad zablokovaných paketů.

Timeout: sledujte zamýšlenou síťovou cestu

Porovnejte cíl z ssh -v s aktuální adresou v panelu. DNS může být zastaralé nebo vést přes jinou IPv6. Potvrďte, zda je VPS veřejný, nebo vyžaduje VPN či jump host.

Ověřte běh instance a veřejné směrování. V síťovém firewallu musí sedět skutečný SSH port i současná veřejná zdrojová IP. Domácí IP se může změnit, zatímco povolení /32 zůstane staré. Firewall hosta zkontrolujte konzolí.

U OCI se uplatňují security lists, NSG, směrování i pravidla image. Instalace UFW nebo vyprázdnění iptables není diagnostický krok. Ponechte původní pravidla a projděte síťový postup Oracle. Samotný neúspěšný ping nedokazuje nefunkční SSH.

Odmítnutí: ověřte port a službu

Odmítnutí neověřuje, že cílem je správný VPS. Potvrďte jeho identitu a port, poté přes fungující přístup nebo konzoli spusťte na serveru:

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

Hledejte listener na správné adrese a portu a srovnejte čas logu s pokusem. Ubuntu může používat socket activation: neaktivní ssh.service samo neznamená nedostupné SSH, pokud naslouchá ssh.socket.

sshd -t kontroluje konfiguraci a host keys, ale nespouští démona. Tichý úspěch neověřuje dosažitelnost sítě. Při chybě určete konkrétní soubor či nastavení před případným reloadem; nerestartujte naslepo.

Odmítnutý klíč: ověřte uživatele a nabídnutou identitu

Použijte skutečný počáteční účet poskytovatele nebo správce, kterého jste vytvořili. Ve výpisu klienta zjistěte nabídnutý otisk. Pro omezení nesouvisejících klíčů agenta zkuste na počítači:

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

Stále mohou platit nakonfigurované IdentityFile; ověřte je přes ssh -G. Nečitelný či příliš otevřený soukromý klíč nejprve opravte na klientovi, nikoli změnou pravidel serveru.

Na serveru zjistěte účet a autorizované klíče. Příklad předpokládá /home/ubuntu; nahraďte jej domovskou cestou z getent.

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

Porovnejte otisky, vlastníka, oprávnění a deník autentizace. Prověřte AuthorizedKeysFile, Include a Match pravidla; poskytovatel může používat vlastní správu klíčů. Existující klíče zachovejte. Nevypínejte StrictModes ani nezapínejte hesla jako maskování příčiny.

Změněný host key: nejdříve ověřte server

Reinstalace nebo přidělení IP jinému stroji může klíč změnit. Nevysvětlená změna může znamenat špatný cíl nebo odposlech. V ověřeném panelu potvrďte ID instance a plánovanou změnu.

V důvěryhodné konzoli přímo na hostu zjistěte veřejný klíč odpovídající algoritmu klienta; pro Ed25519:

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

Porovnejte SHA256 s varováním. Je to klíč serveru, nikoli uživatelský klíč ani klíč brány konzole. Po ověření může být nutné upravit jeho konkrétní uložený záznam; soubor zálohujte a ostatní položky zachovejte. Nemažte celý known_hosts ani nevypínejte kontrolu. Nejasnou identitu nejprve vyšetřete.

Ověřte cílenou opravu novým přihlášením

Opravte prokázanou adresu, uživatele, klíč, úzké síťové pravidlo nebo chybu konfigurace. Při změně zachovejte nezávislý přístup a ověřte syntaxi SSH. Nový port může vyžadovat úpravu socket activation, ne jen restart služby.

Zopakujte původní pokus s vypnutým sdílením spojení. Ověřte správný účet a potřebné sudo. Stará otevřená relace toto nenahrazuje. Zapište příčinu a změnu; pak pokračujte nastavením webu.