SSH ryšio klaidos: patikrinkite priežastį

Užfiksuokite vieną nesėkmingą bandymą

Atidarykite tiekėjo atkūrimo konsolę ir neuždarykite veikiančio SSH. Kliento komandos vykdomos jūsų Linux, macOS arba WSL kompiuteryje, serverio — tik per esamą prieigą ar patikimą konsolę.

203.0.113.10 pakeiskite tikru adresu, ubuntu — paskyra, 22 — prievadu, rakto kelią — savo failu. Pirmoji komanda parodo taikomus nustatymus, antroji bando naują ryšį be ankstesnio ryšio bendrinimo.

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

Peržiūrėkite hostname, user, port, identityfile ir proxy. Užrašykite laiką bei paskutinę klaidą. Naują serverio raktą patvirtinkite pagal tapatybės skyrių žemiau. Prieš dalydamiesi žurnalu pašalinkite jautrius vardus, adresus ir kelius; privataus rakto niekam nesiųskite.

Pasirinkite šaką pagal pranešimą

Mažame ekrane slinkite lentelę į šoną, kad matytumėte visus stulpelius.

Pranešimas susiaurina priežastis, bet neįrodo vienos. Jei prieš timeout jau matote Connection established, tikrinkite SSH derybas ir žurnalus, o ne iškart manykite, kad visi paketai blokuojami.

Timeout: patikrinkite numatytą tinklo kelią

Palyginkite ssh -v adresą su tiekėjo skydeliu. Pasenęs DNS ar kitas IPv6 gali nukreipti į netinkamą mašiną. Žinokite, ar reikia viešo IP, VPN ar tarpinio jump host.

Patikrinkite VM būseną, viešą maršrutą, tikrą SSH prievadą ir dabartinį kompiuterio viešą IP. Namų adresas gali pasikeisti, o sena /32 taisyklė likti. Sistemos ugniasienę tikrinkite konsolėje.

Oracle atveju svarbūs security list, NSG, maršrutai ir atvaizdo ugniasienė. Neišvalykite iptables ir nediekite UFW kaip diagnostikos priemonės. Oracle gidas paaiškina tinklą. Vien nesėkmingas ping neįrodo, kad SSH nepasiekiamas.

Connection refused: patikrinkite paslaugą

Atmetimas nepatvirtina, kad pasiekėte savo VPS. Patikrinkite tapatybę ir prievadą, tada serveryje per esamą prieigą vykdykite informacines komandas.

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

Ieškokite klausančios paslaugos tinkamame adrese ir prievade, sugretinkite žurnalų laiką su bandymu. Ubuntu gali naudoti socket activation: neaktyvi ssh.service savaime nereiškia gedimo, jei klausosi ssh.socket.

sshd -t tikrina konfigūraciją ir serverio raktus nepaleisdamas naujo demono. Tyli sėkmė nepatvirtina tinklo prieigos. Raskite nurodytą klaidingą failą ar parametrą prieš svarstydami konfigūracijos įkėlimą iš naujo.

Publickey: patikrinkite paskyrą ir siūlomą raktą

Naudokite tikrą tiekėjo pradinę ar savo sukurtą paskyrą. Kliento žurnale raskite siūlomo rakto atspaudą. Norėdami sumažinti kitų agento raktų skaičių savo kompiuteryje bandykite:

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

Kiti nustatyti IdentityFile vis tiek gali būti taikomi — peržiūrėkite ssh -G. Jei privatus failas neperskaitomas ar jo teisės per plačios, pirmiausia pataisykite vietinį failą.

Serveryje patikrinkite paskyrą. Pavyzdys numato /home/ubuntu; naudokite tikrą getent grąžintą katalogą.

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

Palyginkite leidžiamų ir siūlomų raktų atspaudus. Patikrinkite nuosavybę, teises, AuthorizedKeysFile, include ir Match taisykles. Tiekėjo raktų valdymas gali naudoti kitą mechanizmą. Išsaugokite esamus raktus; neišjunkite StrictModes ir neįjunkite slaptažodžių vien klaidai paslėpti.

Pasikeitusi tapatybė: patvirtinkite prieš tęsdami

Perinstaliavimas ar iš naujo priskirtas IP gali pakeisti serverio raktą. Netikėtas pasikeitimas taip pat gali reikšti kitą serverį ar perėmimą. Patikrinkite VM ID ir pakeitimo istoriją savo paskyros skydelyje.

Patikimoje svečio konsolėje parodykite viešąjį serverio raktą pagal kliento nurodytą algoritmą. Ed25519 atveju:

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

Palyginkite SHA256 su kliento perspėjimu. Tai serverio, ne jūsų vartotojo ir ne OCI konsolės gateway raktas. Patvirtinę pakeitimą, išsaugokite known_hosts kopiją ir atnaujinkite tik šio serverio įrašą. Nešalinkite viso failo ir neapeikite tikrinimo. Jei tapatybė neaiški, nutraukite prisijungimą.

Pataisymą patvirtinkite nauja sesija

Keiskite tik nustatytą neteisingą adresą, paskyrą, raktą, siaurą tinklo taisyklę ar konfigūracijos klaidą. Išsaugokite nepriklausomą prieigos kelią ir patikrinkite konfigūraciją prieš taikydami pakeitimą. Kitam prievadui gali reikėti ir socket activation nustatymų.

Pakartokite pradinį bandymą be ryšio bendrinimo. Patvirtinkite tinkamą paskyrą ir sudo, jei jis reikalingas. Sena likusi sesija nėra naujo prisijungimo patikra. Užrašykite priežastį ir pakeitimą, tada tęskite serverio paruošimą.

Dažni klausimai