SSH-fejl: brug fejlmeddelelsen til at vælge næste trin

Registrér ét forbindelsesforsøg

Lokale kommandoer køres på din Linux-, macOS- eller WSL-computer. Serverkontroller køres gennem eksisterende SSH-adgang eller en betroet gendannelseskonsol. Erstat dokumentationsadressen 203.0.113.10, brugeren ubuntu, port 22 og nøglestien med de rigtige værdier.

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

ssh -G viser de endelige klientindstillinger: hostname, user, port, identityfile og eventuel proxy. Den anden kommando bruger -S none, så en allerede delt forbindelse ikke genbruges. Registrér tidspunktet og sidste fejl. Skjul brugernavne, adresser og stier ved deling af debugoutput; del aldrig en privat nøgle.

Vælg gren efter fejlen

På en lille skærm kan du rulle tabellen sidelæns.

Meddelelserne afgrænser problemet, men beviser ikke én årsag. Hvis loggen allerede viser Connection established før timeout, skal SSH-håndtrykket og serverloggen også undersøges. En refused-meddelelse autentificerer ikke i sig selv destinationen som din VPS.

Timeout: følg den tiltænkte netværksvej

Sammenlign destinationen i ssh -v med panelets aktuelle IP. Et gammelt DNS-svar eller en forkert IPv6-adresse kan sende forbindelsen et andet sted hen. Afklar, om adgangen kræver offentlig IP, VPN eller en springvært.

Kontroller instansstatus, offentlig routing og udbyderens regler for den faktiske SSH-port og din aktuelle offentlige kildeadresse. En gammel /32-regel kan pege på en adresse, din hjemforbindelse ikke længere bruger. Se gæstens firewall via konsollen.

I Oracle Cloud indgår security lists, NSG’er, routing og gæstefirewall. Bevar imagets regler; installation af UFW eller tømning af iptables er ikke en diagnose. Et mislykket ping beviser heller ikke, at SSH er utilgængelig.

Afvist forbindelse: undersøg tjenesten

Kør på serveren gennem fungerende adgang 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 efter en listener på den ønskede adresse og port, og sammenlign logtidspunktet med forsøget. Ubuntu kan bruge socket-aktivering: en inaktiv ssh.service er ikke alene en fejl, hvis ssh.socket lytter.

sshd -t kontrollerer konfiguration og værtsnøgler uden at starte dæmonen. Et stille succesresultat beviser ikke netværksadgang. Find den konkrete fil eller indstilling ved fejl; genstart ikke blindt en tjeneste, der giver din eneste adgang.

Publickey: kontroller bruger og tilbudt nøgle

Brug initialkontoen fra udbyderen eller en administrator, du selv oprettede. Se i debugloggen, hvilket nøglefingeraftryk klienten tilbyder. Prøv lokalt med:

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

IdentitiesOnly begrænser uvedkommende agentnøgler, men konfigurerede IdentityFile-poster kan stadig gælde. Kontroller ssh -G. Hvis den lokale private nøgle ikke kan læses eller har for åbne rettigheder, skal den fejl løses lokalt først.

Undersøg serverens konto og offentlige nøgler. Eksemplet antager /home/ubuntu; brug hjemmemappen fra 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

Sammenlign de godkendte fingeraftryk med det tilbudte. Kontroller ejer, rettigheder, kontoens politik og journalen. AuthorizedKeysFile, Include, Match eller en administreret nøgletjeneste kan ændre standardmekanismen. Bevar eksisterende nøgler; slå ikke StrictModes fra og aktivér ikke adgangskoder som genvej.

Ændret værtsnøgle: bekræft identiteten

En genopbygning eller ny indehaver af IP-adressen kan ændre nøglen, men en uventet ændring kan også betyde forkert destination. Kontroller instans-ID og planlagte ændringer i det autentificerede udbyderpanel.

Kør via betroet konsol til gæsten for en Ed25519-værtsnøgle:

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

Sammenlign algoritme og SHA256-fingeraftryk med klientens advarsel. Det er serverens nøgle, ikke din login-nøgle eller konsolgatewayens. Efter verificering kan netop denne servers gemte post opdateres; tag først kopi og bevar uvedkommende poster. Slet ikke hele known_hosts, og omgå ikke kontrollen.

Bekræft rettelsen med et nyt login

Ret den påviste adresse, bruger, nøgle, snævre netværksregel eller konfigurationsfejl. Bevar en uafhængig adgangsvej og valider konfiguration før anvendelse. Portændringer kan også kræve ændring af socket-aktivering.

Gentag forsøget uden forbindelsesdeling. Kontroller den forventede konto og nødvendig sudo-adgang. Først derefter kan den oprindelige session afsluttes. Registrér årsag og rettelse, og fortsæt eventuelt med Ubuntu-opsætningen.

Spørgsmål og svar