SSH-feilsøking når VPS-en avviser tilkoblingen

Registrer ett nytt forsøk

Finn leverandørens gjenopprettingskonsoll. Klientkommandoer kjøres på din egen maskin i Linux, macOS eller WSL. Serverkommandoer kjøres gjennom eksisterende tilgang eller den autentiserte konsollen.

Erstatt eksempeladressen 203.0.113.10, ubuntu, port 22 og nøkkelstien med riktige verdier. Skriv først ut klientens beregnede innstillinger, og opprett deretter en ny tilkobling uten deling av en eksisterende forbindelse.

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

Undersøk hostname, user, port, identityfile og proxyinnstillinger. Noter tidspunkt og siste feilmelding. Bekreft nye vertsnøkkelspørsmål gjennom den pålitelige konsollen. Fjern personlige opplysninger fra feillogger før deling, og del aldri private nøkler.

Finn riktig gren i feilsøkingen

På små skjermer kan du rulle tabellen sidelengs for å se alle kolonnene.

Dette er spor, ikke bevis for én årsak. Hvis loggen allerede viser Connection established før timeout, undersøker du håndtrykk og serverlogger i stedet for å anta at all nettverkstrafikk blokkeres.

Ved timeout: følg nettverksveien

Sammenlign måladressen fra ssh -v med panelet. Et domenenavn kan peke til gammel IPv4 eller en annen IPv6-adresse. Avklar om tilgangen krever offentlig adresse, VPN eller en mellomvert.

Kontroller at instansen kjører, at rutingen finnes, og at reglene tillater riktig målport fra din nåværende offentlige IP. Hjemmeforbindelsen kan ha fått ny adresse mens /32-regelen står uendret. Kontroller også gjestebrannmuren via konsollen.

For Oracle virker security lists, NSG, ruter og image-regler sammen. Ikke installer UFW eller tøm iptables som et feilsøkingstrinn. Oppsettsveiledningen beskriver nettverket. Mislykket ping alene fastslår ikke at SSH er utilgjengelig.

Ved avvisning: undersøk den lyttende tjenesten

En avvist forbindelse bekrefter ikke at adressen er din server. Bekreft instans og port. Kjør deretter lesekontrollene på serveren gjennom fungerende tilgang eller konsollen.

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

Se etter en lytter på riktig adresse og port, og sammenhold loggen med tidspunktet for forsøket. Ubuntu kan bruke socket-aktivering: inaktiv ssh.service betyr ikke at SSH er nede når ssh.socket lytter.

sshd -t kontrollerer konfigurasjon og vertsnøkler uten å starte tjenesten. Taus suksess beviser ikke nettverkstilgang. Ved feil må du finne aktuell fil eller innstilling før eventuell omlasting.

Ved publickey-feil: sjekk konto og nøkkel

Bruk leverandørens dokumenterte startkonto eller en administrator du selv opprettet. Se hvilket fingeravtrykk klienten faktisk tilbyr. Begrens uvedkommende agentnøkler med et nytt lokalt forsøk:

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

IdentityFile-oppføringer i konfigurasjonen kan fortsatt gjelde; se ssh -G. En uleselig eller for åpent tilgjengelig privat nøkkelfil løses først på klienten.

Undersøk deretter kontoen og autoriserte offentlige nøkler på serveren. Erstatt /home/ubuntu med hjemmestien fra getent når den er annerledes.

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

Sammenlign fingeravtrykk og se etter eierskaps-, rettighets- eller kontofeil i journalen. Kontroller AuthorizedKeysFile, inkluderte filer og Match-regler. Leverandørstyrt nøkkelhåndtering kan avvike fra standardfilen. Behold eksisterende nøkler; ikke slå av StrictModes eller aktiver passord for å skjule årsaken.

Ved endret identitet: bekreft før innlogging

En reinstallasjon eller gjenbrukt IP kan endre vertsnøkkelen. Et uventet avvik kan også bety feil endepunkt eller avlytting. Bekreft instans-ID og eventuell planlagt endring i panelet.

Se på den offentlige vertsnøkkelen som matcher klientens algoritme gjennom pålitelig konsolltilgang til gjesten. For Ed25519:

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

Sammenlign SHA256 med advarselen. Dette gjelder servernøkkelen, ikke påloggingsnøkkelen eller konsollgatewayen. En bekreftet endring kan kreve oppdatering av akkurat denne vertens lagrede oppføring. Ta kopi først og behold andre oppføringer. Ikke slett hele known_hosts eller omgå kontrollen.

Bekreft rettelsen med en ny økt

Rett den påviste adressen, kontoen, nøkkelen eller avgrensede regelen. Kontroller SSH-konfigurasjonen før endringer tas i bruk, og behold en uavhengig tilgangsvei. En ny port kan kreve endring av socket-aktivering, ikke bare tjenesten.

Gjenta det opprinnelige forsøket med tilkoblingsdeling avslått. Kontroller riktig konto og nødvendig sudo-tilgang. En gammel økt som fortsatt er åpen, er ikke en ny innloggingstest. Noter årsak og rettelse før du fortsetter med nettsideoppsettet.

Spørsmål og svar