SSH-ühenduse vead: leidke tõrke põhjus

Salvestage üks tõrge ja hoidke toimiv ühendus alles

Jätke edukas SSH-seanss avatuks ning leidke pakkuja taastekonsool. Kliendikäsud käivitage oma arvutis Linuxi, macOS-i või WSL-i terminalis. Serverikäsud käivitage olemasoleva ühenduse või autentitud taastekonsooli kaudu, mitte kohalikus terminalis.

Asendage dokumendinäite aadress 203.0.113.10 oma serveri aadressiga ning ubuntu, port 22 ja võtmetee tegelike väärtustega. Vaadake esmalt kliendi rakenduvaid seadeid, seejärel proovige üht uut ühendust.

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

Kontrollige hostname, user, port, identityfile ja puhverserveri seadeid. Teine käsk keelab selle katse jaoks ühenduse jagamise. Salvestage aeg ja lõplik viga. Uut hostivõtme küsimust kontrollige allpool kirjeldatud viisil. Enne silumisväljundi jagamist eemaldage kasutajanimed, aadressid ja teed; privaatvõtit ei jagata.

Valige veale vastav kontroll

Väikesel ekraanil kerige tabelit külgsuunas, et näha kõiki veerge.

Teated kitsendavad otsingut, kuid ei tõesta üht kindlat põhjust. Kui enne aegumist on logis juba Connection established, uurige SSH käepigistust ja serveriloge; kogu liiklus ei olnud tingimata blokeeritud.

Aegumine: jälgige ettenähtud võrguteed

Võrrelge ssh -v sihtaadressi pakkuja paneeli praeguse aadressiga. Vana DNS või teine IPv6-siht võib viia valesse kohta. Kontrollige, kas server vajab avalikku aadressi, VPN-i või hüppeserverit.

Veenduge, et VM töötab ja avalik marsruut on olemas. Kontrollige pakkuja tulemüüris tegelikku SSH sihtporti ja oma praegust avalikku lähteaadressi. Koduse ühenduse aadress võib muutuda, samal ajal kui /32 reegel jääb vanaks. Kontrollige konsoolist ka külalissüsteemi tulemüüri.

Oracle’is mõjutavad ühendust turvaloendid, NSG-d, marsruudid ja külalissüsteemi tulemüür. Säilitage tõmmise reeglid; UFW paigaldamine või iptables tühjendamine pole diagnoosimine. Võrgu ülesehitust kirjeldab Oracle’i seadistusjuhend. Ebaõnnestunud ping ei tõenda üksi SSH puudumist.

Keeldumine: kontrollige kuulavat teenust

Keeldumine ei tõenda, et siht on teie õige server. Kontrollige identiteeti ja porti, seejärel käivitage serveris toimiva ühenduse või taastekonsooli kaudu järgmised lugemiskäsud.

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

Leidke kuulaja õigel aadressil ja pordil ning võrrelge logi katse ajaga. Ubuntu võib kasutada sokliaktiveerimist: passiivne ssh.service ei tähenda SSH puudumist, kui ssh.socket kuulab.

Sshd -t kontrollib seadistust ja hostivõtmete kehtivust deemonit käivitamata. Vaikne edu ei tõenda võrgu kaudu kättesaadavust. Vea korral leidke konkreetne fail või seade enne uuesti laadimist; ärge taaskäivitage pimesi.

Võtme tagasilükkamine: kontrollige kasutajat ja identiteeti

Kasutage pakkuja algset kontot või enda loodud administraatorit, mitte oletatud nime. Leidke kliendi silumislogist pakutud võtme sõrmejälg. Agendi kõrvaliste võtmete vähendamiseks proovige kohalikus terminalis:

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

Seadistatud IdentityFile kirjed võivad endiselt rakenduda; uurige ssh -G tulemust. Kui privaatvõti pole loetav või faili õigused on liiga avarad, parandage kohalikku faili enne serveri muutmist.

Uurige serveris sihtkontot ja lubatud avalikke võtmeid. Näide eeldab kodukataloogi /home/ubuntu; asendage see getent’i näidatud teega.

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

Võrrelge lubatud võtmete sõrmejälgi pakutuga. Otsige logist omandi, õiguste ja kontopoliitika vigu. Vaikimisi teest erineva seadistuse korral kontrollige AuthorizedKeysFile, kaasatud faile ja Match reegleid. Pakkuja võtmehaldusteenus võib samuti mehhanismi muuta. Säilitage olemasolevad võtmed; ärge lülitage StrictModes välja ega lubage paroolidega sisselogimist vea peitmiseks.

Muutunud hostivõti: tõendage serveri identiteet

Uuesti paigaldus või IP ümberjagamine võib võtit muuta, kuid ootamatu muutus võib tähendada valet sihti või pealtkuulamist. Kontrollige autentitud pakkujapaneelis instantsi tunnust ja kavandatud uuesti paigaldust.

Vaadake usaldatud konsoolis külalissüsteemi avalikku hostivõtit, mille algoritmi klient näitab. Ed25519 jaoks kasutage:

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

Võrrelge SHA256 sõrmejälge kliendi hoiatusega. See on serveri võti, mitte kasutaja sisselogimisvõti ega konsoolilüüsi võti. Kontrollitud asendus võib nõuda selle serveri salvestatud kirje uuendamist; tehke failist koopia ja säilitage teised kirjed. Ärge kustutage tervet known_hosts faili ega keelake kontrolli. Selgitamata identiteedimuutuse korral peatage ühendus.

Kontrollige parandust uues seansis

Parandage leitud aadress, kasutaja, võti, kitsas võrgureegel või seadistusviga. Serveri muutmise ajal säilitage sõltumatu ligipääs ning kontrollige SSH seadistust enne rakendamist. Pordi muutmine võib vajada ka sokliaktiveerimise seadistust.

Korrake algset katset ühenduse jagamiseta. Kontrollige uut sisselogimist õigesse kontosse ja vajalikku sudo õigust. Vana seansi püsimine ei asenda seda testi. Salvestage põhjus ning muudatus, seejärel jätkake VPS-i seadistamist.

Korduma kippuvad küsimused