Felsöka SSH: utgå från det exakta felmeddelandet

Spara felet och behåll åtkomsten

Låt en fungerande SSH-session vara öppen och hitta återställningskonsolen. Klientkommandon körs lokalt i Linux, macOS eller WSL; serverkommandon körs genom befintlig åtkomst eller betrodd konsol. Blanda inte terminalerna.

Byt dokumentationsadressen 203.0.113.10, användaren ubuntu, port 22 och nyckelfilen till dina värden. Kör lokalt:

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

Granska hostname, user, port, identityfile och proxyinställningar. Andra kommandot stänger av delning av anslutningar för detta försök. Notera tid och sista fel; verifiera en ny värdnyckel enligt nedan. Maskera adresser och användarnamn i delade loggar och dela aldrig privata nycklar.

Välj gren efter felmeddelandet

På en liten skärm kan du rulla tabellen i sidled för att se alla kolumner.

Detta är ledtrådar, inte bevis för en enda orsak. Om Connection established visas före en timeout behöver även handskakningen och serverloggarna undersökas.

Timeout: följ den avsedda nätvägen

Jämför destinationen i ssh -v med leverantörspanelen. Ett värdnamn kan peka på gammal DNS eller en annan IPv6-adress. Kontrollera om anslutningen ska gå via offentlig IP, VPN eller en hoppvärd.

Kontrollera att instansen körs, routningen finns och rätt SSH-port tillåts från din aktuella publika adress. En /32-regel kan bli inaktuell när hemanslutningens adress ändras. Kontrollera även gästbrandväggen via konsolen.

I OCI samverkar security lists, NSG, routning och gästregler. Bevara de levererade reglerna; UFW-installation eller tömning av iptables är inte felsökning. Se Oracle-nätverksexemplet. Ett misslyckat ping bevisar inte ensamt att SSH är otillgängligt.

Nekad anslutning: kontrollera tjänsten

En refusal autentiserar inte maskinen som din VPS. Kontrollera först identitet och port. Kör sedan läsande kontroller på servern genom fungerande åtkomst eller konsol:

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

Leta efter rätt port och lyssningsadress och jämför loggtiden med försöket. Ubuntu kan använda socket activation: inaktiv ssh.service betyder inte alltid att SSH är nere om ssh.socket lyssnar.

sshd -t validerar konfiguration och värdnycklar utan att starta tjänsten. Tyst framgång bevisar inte nätåtkomst. Utred det specifika felet innan du överväger omladdning.

Publickey-fel: kontrollera konto och nyckel

Använd ett verifierat konto, inte ett gissat användarnamn. Se vilket fingeravtryck klienten erbjuder. För att minska orelaterade agentnycklar kan du prova lokalt:

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

Konfigurerade IdentityFile kan fortfarande gälla; granska ssh -G. Lös först lokal oläsbar nyckelfil eller alltför öppna filrättigheter. På servern kontrolleras rätt konto och dess publika nycklar. Byt /home/ubuntu till hemkatalogen från 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

Jämför auktoriserade fingeravtryck med det erbjudna. Läs journalen om ägare, rättigheter och kontopolicy. Kontrollera AuthorizedKeysFile, inkluderade filer, Match-regler och eventuell leverantörsstyrd nyckelhantering. Bevara befintliga nycklar; slå inte av StrictModes eller på lösenord för att dölja orsaken.

Ändrad värdnyckel: verifiera först

En ominstallation eller ny tilldelning av IP kan ändra nyckeln, men avvikelsen kan också betyda fel ändpunkt eller avlyssning. Bekräfta instans-ID och eventuell planerad förändring via ditt autentiserade konto.

Läs den publika värdnyckeln för rätt algoritm genom betrodd konsolåtkomst till gästen. För Ed25519:

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

Jämför SHA256 med klientens varning. Detta är servernyckeln, inte din inloggningsnyckel eller konsolgatewayens nyckel. Efter verifierad ändring kan just den sparade posten behöva uppdateras; säkerhetskopiera filen och bevara andra poster. Radera inte hela known_hosts och kringgå inte kontrollen.

Testa korrigeringen i en ny session

Ändra bara den identifierade orsaken: adress, användare, nyckel, snäv nätregel eller konfigurationsfel. Behåll oberoende åtkomst och validera SSH-konfiguration innan en serverändring tas i bruk. Byte av port kan också kräva ändring i socket activation.

Upprepa ursprungsförsöket utan anslutningsdelning. Kontrollera rätt konto och nödvändig sudo-åtkomst. En gammal session räknas inte. Anteckna felet och åtgärden och återgå vid behov till installationen.