Gabimet e lidhjes SSH në Ubuntu VPS: gjeni shkakun
Kur lidhja SSH me Ubuntu VPS dështon, filloni nga mesazhi dhe faza e gabimit. Ky udhëzues ndan problemet e rrjetit, shërbimit, autentikimit dhe identitetit të serverit, duke ruajtur çdo akses që ende punon.
VPSuntu · Përditësuar: · Leximi: rreth 5 min
Përmbajtja e udhëzuesit
Regjistroni një dështim dhe ruani aksesin
Mbajeni sesionin funksional të hapur dhe gjeni konsolën e rikuperimit të ofruesit. Komandat e klientit ekzekutohen në kompjuterin tuaj Linux, macOS ose WSL; ato të serverit në sesionin ekzistues ose konsolën e autentikuar.
Zëvendësoni adresën shembull 203.0.113.10, përdoruesin ubuntu, portën 22 dhe shtegun e çelësit me vlerat reale. Fillimisht shfaqni cilësimet efektive, pastaj provoni një lidhje të re.
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.10Shikoni hostname, user, port, identityfile dhe proxy. Prova çaktivizon connection sharing që të mos përdorë një lidhje të vjetër. Shënoni kohën dhe gabimin e fundit. Verifikoni çdo host key të ri me burim të besuar. Hiqni përdoruesit, adresat e shtigjet private nga debug para ndarjes; mos dërgoni kurrë çelës privat.
Zgjidhni kontrollin sipas fazës së gabimit
Në ekran të vogël, lëvizeni tabelën anash për të parë të gjitha kolonat.
| Mesazhi ose faza | Kuptimi fillestar | Kontrolli i radhës |
|---|---|---|
| Timeout para Connection established | Lidhja TCP nuk u përfundua | Adresa, ruta, firewall dhe gjendja e instancës |
| Connection refused | Refuzim aktiv në atë adresë e port | Porta, listener dhe rregullat e refuzimit |
| Permission denied (publickey) | U arrit autentikimi, por kredencialet dështuan | Përdoruesi, çelësi i ofruar dhe politika e serverit |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Identitet ndryshe nga ai i ruajtur | Verifikimi i besuar i çelësit përpara vazhdimit |
Këta tregues e ngushtojnë kërkimin, por nuk provojnë një shkak të vetëm. Nëse Connection established shfaqet para timeout, hetoni handshake SSH dhe logs në server, pa supozuar se të gjitha paketat bllokohen.
Timeout: ndiqni rrugën e synuar të rrjetit
Krahasoni destinacionin e ssh -v me adresën aktuale në panel. DNS i vjetër ose IPv6 tjetër mund ta çojë lidhjen diku tjetër. Konfirmoni nëse VPS kërkon IP publike, VPN apo jump host.
Kontrolloni gjendjen Running dhe rrugën publike. Firewall i ofruesit duhet të lejojë portën reale SSH nga IP-ja juaj aktuale. Një lidhje shtëpie mund të ndryshojë adresë ndërsa /32 mbetet i vjetër. Kontrolloni përmes konsolës edhe firewall e sistemit.
Në Oracle kanë rëndësi security lists, NSG, routing dhe firewall guest. Mos instaloni UFW dhe mos zbrazni iptables për diagnostikim. Udhëzuesi Oracle Ubuntu shpjegon rrjetin. Dështimi i ping vetëm nuk provon se SSH është i paarritshëm.
Connection refused: kontrolloni shërbimin që dëgjon
Refuzimi nuk autentikon destinacionin si VPS tuaj. Konfirmoni identitetin e portën dhe ekzekutoni në server, përmes aksesit ekzistues ose konsolës:
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-pagerKërkoni listener në portën dhe adresën e pritur dhe lidhni logs me kohën e provës. Ubuntu mund të përdorë socket activation: ssh.service joaktiv nuk provon mungesë SSH nëse ssh.socket dëgjon.
sshd -t kontrollon konfigurimin dhe vlefshmërinë e çelësave pa nisur daemon. Suksesi pa dalje nuk provon rrjetin. Nëse ka gabim, identifikoni skedarin ose cilësimin para reload; mos rindizni verbërisht.
Publickey: kontrolloni llogarinë dhe çelësin e ofruar
Përdorni përdoruesin fillestar të ofruesit ose administratorin që krijuat. Në debug lokal gjeni fingerprint e çelësit të ofruar. Për të kufizuar çelësa të tjerë nga agent, provoni lokalisht:
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10IdentityFile në konfigurim mund të vazhdojë të zbatohet; shikoni ssh -G. Nëse skedari privat nuk lexohet ose ka leje tepër të hapura, korrigjoni atë skedar lokal para ndryshimit të serverit.
Në server kontrolloni llogarinë dhe çelësat e autorizuar. Shembulli përdor /home/ubuntu; zëvendësojeni me home që kthen 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_keysKrahasoni fingerprints dhe hetoni pronësinë, lejet e politikën e llogarisë në journal. AuthorizedKeysFile, snippets Include, Match ose shërbime çelësash të ofruesit mund të ndryshojnë mekanizmin. Ruani çelësat ekzistues. Mos çaktivizoni StrictModes ose aktivizoni fjalëkalime për të fshehur shkakun.
Host key i ndryshuar: verifikoni identitetin
Rindërtimi ose ricaktimi i IP-së mund të ndryshojë çelësin; një ndryshim i papritur mund të jetë destinacion i gabuar ose ndërhyrje. Në panel të autentikuar konfirmoni ID-në e instancës dhe rindërtimin e planifikuar.
Në konsolën e besuar të guest kontrolloni çelësin publik të algoritmit të shfaqur. Për Ed25519:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256Krahasoni SHA256 me paralajmërimin e klientit. Është çelësi i serverit, jo çelësi juaj i hyrjes ose i portës së konsolës së ofruesit. Pas zëvendësimit të verifikuar, ruani kopje të known_hosts dhe përditësoni vetëm hyrjen e atij serveri. Mos fshini gjithë skedarin dhe mos anashkaloni kontrollin. Nëse identiteti mbetet i pashpjeguar, ndaloni lidhjen.
Provoni korrigjimin në një sesion të ri
Korrigjoni vetëm adresën, përdoruesin, çelësin, rregullin e ngushtë ose gabimin e konfirmuar të konfigurimit. Ruani një rrugë tjetër aksesi dhe validoni konfigurimin SSH para aplikimit. Portë e re mund të kërkojë ndryshim socket activation, jo vetëm restart shërbimi.
Përsëritni provën me connection sharing të çaktivizuar. Konfirmoni llogarinë e synuar dhe sudo të nevojshëm. Sesioni i vjetër ende i lidhur nuk është provë e hyrjes së re. Shënoni gabimin dhe ndryshimin, pastaj vazhdoni konfigurimin e Ubuntu VPS.
Pyetje të shpeshta
A duhet ta riinstaloj Ubuntu për të rregulluar SSH?
Diagnostikoni fillimisht. Adresa, përdoruesi ose çelësi i gabuar nuk kërkon riinstalim, i cili mund të fshijë të dhënat. Pa akses, përdorni rikuperimin e ofruesit.
A provon konsola funksionale që SSH duhet të punojë?
Jo. Konsola dhe SSH publik ndjekin rrugë të ndryshme. Listener, autentikimi dhe rregullat e rrjetit duhet të lejojnë lidhjen SSH.