SSH-yhteysongelmat: etene virheilmoituksen mukaan
SSH-yhteysongelman korjaus alkaa täsmällisestä virheilmoituksesta. Aikakatkaisu, yhteyden hylkäys, kirjautumisavaimen virhe ja palvelinavaimen vaihtuminen vaativat eri tarkistukset. Säilytä toimiva yhteys tai varmista palautuskonsoli ennen muutoksia.
VPSuntu · Päivitetty · Lukuaika noin 4 min
Tämän oppaan sisältö
Tallenna virhe ja todelliset yhteysasetukset
Seuraavat paikalliset komennot sopivat Linuxin, macOS:n ja WSL:n Bashiin. Korvaa ubuntu, 203.0.113.10, portti 22 ja avainpolku omilla tiedoillasi. Palvelimella tehtävät tarkistukset tehdään toimivassa vanhassa istunnossa tai luotetussa palautuskonsolissa.
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.10ssh -G näyttää lopulliset asetukset, kuten hostname-, user-, port-, identityfile- ja proxy-valinnat. -v tulostaa etenemisen ja -S none estää vanhan jaetun yhteyden hyödyntämisen. Kirjaa kellonaika ja viimeinen virhe; peitä tunnisteet ennen lokin jakamista.
Paikanna vaihe, jossa yhteys epäonnistuu
Pienellä näytöllä voit vierittää taulukkoa sivusuunnassa.
| Virhe tai havainto | Ensisijainen rajaus |
|---|---|
| Timeout ennen TCP-yhteyden muodostumista | IP, reititys ja yhteyden sallivat verkkosäännöt |
| Connection refused | Osoitteesta tulee aktiivinen hylkäys; kuuntelija tai sääntö voi puuttua |
| Permission denied (publickey) | Yhteys etenee tunnistautumiseen, mutta käyttäjäavain ei kelpaa |
| Host key changed | Palvelimen henkilöllisyys on vahvistettava luotettua reittiä |
Jos lokissa näkyy Connection established ennen aikakatkaisua, tutki myös SSH-kättelyä ja palvelinlokeja. Kaikki aikakatkaisut eivät ole sama palomuurivika. Refused-vastaus ei yksin todista, että osoite kuuluu oikealle koneelle.
Tarkista verkko avaamatta SSH:ta kaikille
Varmista koneen tila, julkinen osoite ja DNS:n A/AAAA-tietueet. Tarkista VPN, välityspalvelin, hyppykone ja reititys. Tarkista sekä palveluntarjoajan että vieraskoneen säännöt todelliselle SSH-portille ja työaseman nykyiselle julkiselle /32-osoitteelle.
Epäonnistunut ping ei todista SSH:n olevan poikki. Oracle-kuvassa säilytä levykuvan palomuurisäännöt; älä tyhjennä iptablesia tai ota UFW:tä hätäkorjauksena käyttöön. Laaja sisääntulosääntö voi edelleen sallia liikenteen, vaikka lisäisit kapeamman rinnalle.
Tarkista SSH-palvelu luotetusta istunnosta
Aja palvelimella:
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-pagerUbuntu voi käyttää socket-aktivointia: aktiivinen ssh.socket voi kuunnella, vaikka ssh.service ei olisi jatkuvasti käynnissä. Tarkista ss-tulosteesta osoite ja portti. sshd -t kertoo asetusten syntaksista, ei verkkoreitin toimivuudesta.
Lue viimeisen 15 minuutin lokit ja vertaa paikallisen testin aikaan. Älä käynnistä palvelua sokkona uudelleen kesken ainoan toimivan yhteyden. Porttimuutokset on sovitettava myös socket-aktivointiin.
Rajaa käyttäjäavainongelma
Aja omalla tietokoneella yhteys määritetyllä avaimella:
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10IdentitiesOnly rajoittaa agentin tarjoamia avaimia, mutta SSH-asetusten IdentityFile-rivit voivat edelleen vaikuttaa valintaan; tarkista ssh -G. Jos yksityinen avain ei ole luettavissa tai sen paikalliset oikeudet ovat liian väljät, korjaa oma tiedosto ensin.
Tarkista palvelimella käyttäjän oikea kotihakemisto, .ssh-hakemisto ja hyväksytyt julkiset avaimet:
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keysVaihda ubuntu ja /home/ubuntu oikean tunnuksen tietoihin. Vertaa avainsormenjälkiä ja tarkista tiedostojen omistajat ja käyttöoikeudet. Selvitä myös AuthorizedKeysFile-, Match- ja Include-asetukset sekä mahdollinen keskitetty avainten hallinta. Säilytä muiden toimivat avaimet. Älä poista StrictModes-tarkistusta tai avaa salasanakirjautumista virheen kiertämiseksi.
Vahvista muuttunut palvelinavain
Koneen uudelleenluonti tai IP:n siirtyminen toiselle koneelle voi selittää muutoksen, mutta myös väärä palvelin on mahdollinen. Tarkista koneen tunniste ja muutoshistoria kirjautuneena palveluntarjoajan paneeliin. Aja seuraava vain luotetussa vieraskoneen konsolissa:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256Vertaa SHA256-sormenjälkeä ja avaintyyppiä asiakkaan varoitukseen. Kyse on vieraskoneen SSH-host key -avaimesta, ei omasta kirjautumisavaimestasi tai tarjoajan konsoliyhteyden avaimesta.
Kun henkilöllisyys on vahvistettu, varmuuskopioi known_hosts ja päivitä vain kyseinen tarkistettu merkintä. Älä poista koko tiedostoa tai kytke palvelinavaimen tarkistusta pois.
Todista korjaus uudella yhteydellä
Testaa erillinen uusi yhteys ilman yhteyden jakamista, varmista oikea käyttäjä ja tarvittava sudo-oikeus. Vanha avoin istunto ei todista uuden kirjautumisen onnistumista. Sulje alkuperäinen pääsy vasta tämän jälkeen.
Kirjaa korjattu syy ja asetusten muutos. Käyttöönotto-ohje auttaa uuden ylläpitotunnuksen perustamisessa; varmuuskopiointiharjoitus auttaa palautusvalmiuden tarkistamisessa.
Kysymyksiä ja vastauksia
Auttaako palomuurin poistaminen käytöstä?
Se voi avata tarpeettomia palveluja eikä tunnista virheen syytä. Tarkista oikea portti, osoite ja sääntö hallitusti.
Miksi väärä avain tuottaa publickey-virheen?
SSH-palvelin ei hyväksy tarjottua avainta kyseiselle käyttäjälle. Tarkista sekä tunnus että julkisen ja yksityisen avaimen vastaavuus.
Voiko host key -varoituksen vain hyväksyä?
Vahvista ensin kone luotetusta konsolista. Varoituksen hyväksyminen ilman tarkistusta poistaa olennaisen henkilöllisyysvarmistuksen.