Praktični vodič / Dijagnostika SSH-a

SSH veza ne radi: dijagnostika prema poruci pogreške

Kada SSH veza ne radi, poruka pogreške pomaže odabrati sljedeću provjeru. Istek vremena, odbijena veza, odbijen ključ i promijenjen identitet poslužitelja imaju različite uzroke. Za vrijeme dijagnostike sačuvajte svaki pristup koji još radi.

· Ažurirano · Oko 5 min čitanja

Sadržaj vodiča

Zabilježite jedan neuspjeli pokušaj

Ostavite radnu SSH sesiju otvorenu i pronađite provjerenu konzolu za oporavak. Klijentske naredbe pokrećite na svojem Linux, macOS ili WSL računalu. Serverske naredbe pokrećite kroz postojeću vezu ili konzolu, ne u lokalnom terminalu.

Dokumentacijsku IP adresu 203.0.113.10, korisnika ubuntu, port 22 i putanju ključa zamijenite stvarnim vrijednostima. Najprije ispišite primijenjene postavke klijenta, zatim pokušajte novu vezu:

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

Provjerite hostname, user, port, identityfile i eventualni proxy. Druga naredba za ovaj pokušaj isključuje dijeljenje veze. Zapišite vrijeme i konačnu pogrešku. Novi host ključ provjerite kako je opisano niže. Prije dijeljenja ispisa uklonite privatna imena, adrese i putanje; nikad ne šaljite privatni ključ.

Odaberite provjeru prema fazi pogreške

Na malom zaslonu pomaknite tablicu vodoravno za pregled svih stupaca.

Poruka ili fazaŠto upućujeSljedeća provjera
Connection timed out prije uspostave vezeTCP povezivanje nije završiloAdresa, ruta, vatrozidi i stanje stroja
Connection refusedAktivno odbijanje na adresi i portuOčekivani port, usluga i pravila odbijanja
Permission denied (publickey)SSH je došao do autentikacijeRačun, ponuđeni ključ i politika servera
REMOTE HOST IDENTIFICATION HAS CHANGEDKljuč se razlikuje od spremljenogProvjera identiteta kroz pouzdanu konzolu

Poruka sužava problem, ali sama ne dokazuje uzrok. Ako prije isteka vremena piše Connection established, istražite SSH razmjenu i dnevnike servera; ne pretpostavljajte da su svi paketi blokirani.

Kod isteka vremena pratite mrežnu putanju

Usporedite odredište iz ssh -v s aktualnom adresom u panelu. Stari DNS ili drugo IPv6 odredište mogu poslati vezu pogrešnom stroju. Potvrdite treba li javna adresa, VPN ili posredni server.

Provjerite stanje instance, javno usmjeravanje, stvarni SSH port i trenutačnu javnu adresu klijenta. Kućna IP adresa može se promijeniti dok /32 pravilo ostane staro. Kroz konzolu provjerite i vatrozid sustava.

U Oracleu pregledajte security lists, NSG-ove, rute i pravila slike. Instalacija UFW-a ili pražnjenje iptables pravila nije dijagnostički korak. Oracle postupak opisuje mrežu. Neuspjeli ping sam ne dokazuje nedostupnost SSH-a.

Kod odbijene veze provjerite uslugu

Odbijanje ne potvrđuje identitet odredišta. Provjerite da je to pravi VPS i port pa kroz radni pristup ili konzolu izvršite serverske provjere:

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

Tražite uslugu koja sluša na očekivanom portu i adresi te usporedite vrijeme pokušaja s dnevnikom. Ubuntu može koristiti aktivaciju putem socketa: neaktivna ssh.service ne znači kvar ako sluša ssh.socket.

sshd -t provjerava konfiguraciju i ključeve bez pokretanja demona. Tih uspjeh nije test mrežne dostupnosti. Kod pogreške prvo pronađite datoteku ili postavku; nemojte naslijepo ponovno pokretati uslugu.

Kod odbijenog ključa provjerite račun i identitet klijenta

Koristite početni račun pružatelja ili administratora kojeg ste stvorili. U lokalnom ispisu pronađite otisak ponuđenog ključa. Da smanjite ponudu drugih ključeva agenta, na računalu pokušajte:

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

Postavke IdentityFile iz konfiguracije i dalje mogu vrijediti; pregledajte ssh -G. Ako klijent ne može čitati ključ ili odbija njegove preširoke dozvole, prvo uredite pristup lokalnoj datoteci.

Na serveru provjerite račun i ovlaštene javne ključeve. Primjer koristi /home/ubuntu; zamijenite ga direktorijem koji vrati 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

Usporedite ponuđene i ovlaštene otiske. U dnevniku potražite problem vlasništva, dozvola ili politike računa. Provjerite AuthorizedKeysFile, uključene konfiguracije i Match pravila. Pružatelj može koristiti svoju uslugu ključeva. Čuvajte postojeće zapise; nemojte isključivati StrictModes ili uključivati zaporke samo da sakrijete uzrok.

Promijenjen host ključ najprije objasnite

Ponovna instalacija ili druga dodjela IP-a može promijeniti ključ, ali neočekivana promjena može upućivati i na pogrešan stroj ili presretanje. U provjerenom panelu potvrdite identifikator instance i planirane promjene.

U pouzdanoj konzoli gosta provjerite javni ključ istog algoritma koji pokazuje klijent. Za Ed25519:

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

Usporedite SHA256 s upozorenjem. To je ključ poslužitelja, ne vaš prijavni ključ niti ključ konzolnog pristupnika. Tek nakon potvrđene promjene ažurirajte taj zapis: napravite kopiju known_hosts i sačuvajte ostale zapise. Nemojte brisati cijelu datoteku ni zaobilaziti provjeru. Ako identitet nije objašnjen, prekinite povezivanje i istražite.

Potvrdite popravak novom prijavom

Ispravite pronađenu adresu, račun, ključ, usko mrežno pravilo ili postavku. Pri promjeni servera sačuvajte neovisan pristup i provjerite SSH konfiguraciju prije primjene. Promjena porta može uključivati i socket postavke.

Ponovite prvotni pokušaj bez dijeljenja veze. Provjerite da nova prijava vodi na pravi račun i da potrebno sudo radi. Stara otvorena sesija nije taj test. Zabilježite uzrok i promjenu pa se vratite na postavljanje weba.

Pitanja i odgovori

Trebam li ponovno instalirati Ubuntu zbog SSH-a?

Najprije utvrdite uzrok. Pogrešna IP adresa, korisnik ili ključ ne zahtijevaju instalaciju koja može uništiti podatke. Bez radnog pristupa koristite oporavak pružatelja.

Znači li radna konzola da SSH mora raditi?

Ne. Konzola i javni SSH koriste različite putanje. Usluga, autentikacija i mrežna pravila i dalje moraju dopuštati novu SSH vezu.

Primjeri dijagnostike temelje se na dokumentaciji i nisu izvršeni na vašem serveru. Svaka promjena treba odgovarati utvrđenom stanju i sačuvati pristup za oporavak.

Sljedeći koristan korak