Advarsel: Fjernværtsidentifikation er ændret, og hvordan man løser det

SSH er en sikker netværksprotokol, der skaber en krypteret tunnel mellem systemerne. Det er fortsat populært blandt udviklere, der har brug for fjernadgang til computere uden at kræve en grafisk brugergrænseflade. Selvom SSH har eksisteret i årtier og har tjent utallige brugere pålideligt, kan det stadig være påvirket af visse fejl.

Mange af disse fejl er blevet velkendte i SSH-samfundet, og deres løsninger er bredt dokumenteret. Disse omfatter firewall-inkompatibilitet, SSH offentlige nøgleindsprøjtningsproblemer, Problemer med SSH-filnøgletilstand, og fejlen "Advarsel: Fjernværtsidentifikation er ændret".

Denne fejl opstår på tværs af alle større operativsystemer, inklusive Windows, Linux og macOS. Kilden til problemet kan være et legitimt sikkerhedsproblem snarere end en simpel teknisk fejl. I denne artikel vil vi forklare, hvorfor dette sker, hvad det betyder for din SSH-forbindelsessikkerhed, og hvordan du løser det på hver større platform.

Hvad udløser advarslen: Fjernværtsidentifikation er ændret (og bør du bekymre dig?)

"Advarsel: Fjernværtsidentifikation er ændret" vises, når den offentlige SSH-nøgle, der er gemt i din kendte_værter fil matcher ikke den nøgle, serveren præsenterer i øjeblikket. Denne uoverensstemmelse udløser SSHs indbyggede sikkerhedsmekanisme for at beskytte dig mod potentielle trusler.

Legitime årsager til værtsnøgleændringer

Flere uskyldige grunde forklarer, hvorfor en servers værtsnøgle kan ændre sig. Nogle gange vil du se variationer som "RSA-værtsnøgle er ændret", afhængigt af den specifikke nøgletype, der bruges.

Infografik, der viser serverændringer, der ændrer SSH-værtsnøgler, inklusive OS-opgraderinger, servergenopbygninger, backupgendannelse, fysisk til virtuel migrering og SSH-konfigurationsnulstillinger.
Server-relaterede ændringer:

Serveroperativsystemet blev geninstalleret eller opgraderet
Serveren blev genopbygget eller gendannet fra backup
Serverens SSH-konfiguration blev nulstillet
Den fysiske eller virtuelle maskine blev udskiftet
Server migrering til ny hardware

Ændringer af netværkskonfiguration:

Cloud-udbydere genbruger IP-adresser over tid, eller din forbindelse går gennem en belastningsbalancer.
DHCP gentildelte en IP-adresse til en anden maskine
En dekommissioneret servers IP blev tildelt et nyt system
DNS-poster blev opdateret til at pege på en anden server

Netværksdiagram, der viser en DHCP-server, der tildeler dynamiske IP-adresser til virtuelle maskiner, hvor servernedlukning og genudgivelse forårsager SSH-værtsnøglekonflikter.

Nøglestyringshandlinger:

Systemadministratorer regenererede manuelt værtsnøgler af sikkerhedsmæssige årsager
SSH-serversoftwaren blev geninstalleret
Sikkerhedspolitikker krævede nøglerotation

Det er vigtigt at erkende, at ændringer af brugeradgangskode ikke påvirker værtsnøgler. Disse repræsenterer separate autentificeringsmekanismer. Værtsnøgler ændres kun, når selve serveren eller dens SSH-konfiguration ændres.

Hvornår skal man tage advarslen alvorligt

Selvom mange værtsnøgleændringer er legitime, kan dette indikere en ægte sikkerhedstrussel. Du bør være bekymret, hvis:

Du foretog ingen ændringer på serveren eller kendte til planlagt vedligeholdelse
Du kan ikke bekræfte årsagen til nøgleændringen hos serveradministratoren
Serveren tilgås via offentlige netværk eller upålidelige forbindelser
Du opretter forbindelse til produktionssystemer eller servere, der indeholder følsomme data

Opdelt skærm, der sammenligner legitime SSH-ændringer vist i grønt med sikkerhedstrusselsscenarier i rødt, med en hættebeklædt figur, der repræsenterer mand-i-midten-angreb.
Man-in-the-middle-angreb forekommer, selvom de er relativt sjældne. I sådanne angreb placerer en modstander sig mellem din computer og den legitime server og opsnapper al trafik.

Menneskelig fejl og social engineering står for 68% af sikkerhedsbrud, hvilket gør årvågenhed nøglen. Du kan beskytte dine systemer yderligere ved at lære om forebyggelse af brute-force angreb.

Nylige statistikker fra IBM viser, at den globale gennemsnitlige pris for en databrud var $4,44 millioner i 2025, med detektionstider på i gennemsnit otte måneder. Dette viser, hvorfor SSH's værtsnøglebekræftelsesmekanisme eksisterer, og hvorfor du aldrig bør ignorere disse advarsler uden undersøgelse.

Sådan bekræfter du, om advarslen er sikker

Før du fortsætter med at løse problemet, skal du tage disse bekræftelsestrin:

Flowchart, der viser fem verifikationsmetoder til bekræftelse af legitime SSH-værtsnøgleændringer, inklusive teamkonsultation, hostingudbyderkontakt, sikre kanaler og fingeraftrykssammenligning.

Tjek med dit team: Hvis du deler serveradgang, så spørg kollegerne, om de har foretaget ændringer
Gennemgå serverlogfiler: Tjek vedligeholdelsesregistreringer eller ændringslogfiler for seneste aktivitet
Kontakt din hostingudbyder: Hvis du bruger cloud-tjenester, skal du kontrollere, om vedligeholdelse fandt sted
Brug en sikker kanal: Hvis det er muligt, skal du oprette forbindelse via et kendt sikkert netværk for at bekræfte fingeraftrykket
Sammenlign fingeraftryk: Nogle hostingudbydere viser aktuelle SSH-fingeraftryk i deres kontrolpaneler

Hvis du kan bekræfte, at nøgleændringen var legitim, kan du roligt fortsætte med at fjerne den gamle nøgle og acceptere den nye.

Hvis du vil undgå dynamisk IP-omfordeling eller værtsnøglekonflikter, spiller den infrastruktur du vælger en stor rolle.

Cloudzy giver SSH VPS hosting med dedikerede statiske IP'er. Du kører på AMD Ryzen 9-processorer med NVMe-lagring til øjeblikkelig kommandoudførelse. Vores netværk når 40 Gbps på tværs af 12 globale lokationer. Derudover inkluderer vi gratis DDoS-beskyttelse for at holde din forbindelse sikker.

Sådan rettes fejlen "Remote Host Identification has Changed".

Rettelsen er enkel: Fjern den gamle nøglepost fra dit system. Dette fjerner uoverensstemmelsen og lader dig gemme den nye nøgle, næste gang du opretter forbindelse. Tjek vores guide på SSH klienter for flere værktøjer.

Plus, du kan gøre dette med en enkelt kommando eller ved at redigere filen manuelt.

Metode 1: Kommandolinjen (hurtigste)

Denne metode virker til macOS, Linux og Windows 10+ (ved hjælp af OpenSSH). Det er den hurtigste måde at løse fejlen på. For mere info kan du læse ssh-keygen man page.

Åbn din terminal.
Kør denne kommando (erstat værtsnavn med din servers IP eller domæne):

ssh-keygen -R hostname

This command automatically finds the old key in your known_hosts file and deletes it.  Method 2: Manual File Editing (macOS)

Hvis du foretrækker en visuel editor, kan du selv slette nøglen. Fejlmeddelelsen fortæller dig normalt præcist, hvilket linjenummer du skal fjerne.

Åbn din terminal og rediger filen med Nano:

nano ~/.ssh/known_hosts

Find linjen fra din fejlmeddelelse. Slet den, og tryk derefter på Ctrl + X og Y at gemme.

macOS-terminalvindue, der viser nano-tekstredigeringsprogrammet åbent med den kendte_hosts-fil, fremhæver linjen, der skal slettes med nummererede trin og vist gemte instruktioner.

Løsning til Windows

Windows-brugere bruger typisk enten den indbyggede OpenSSH-klient eller PuTTY.

Mulighed 1: Windows OpenSSH (Windows 10/11)

På Windows 10 og 11 er OpenSSH en valgfri funktion. Tilføj det via Indstillinger > Apps > Valgfri funktioner. Server 2025 inkluderer klienten, men du skal slå den til.

Hvis du bruger PowerShell eller kommandoprompt, ssh-keygen kommando fra metode 1 virker også her.

For at redigere filen manuelt i stedet:

Trykke Windows-tast + R.
Type %BRUGERPROFIL%\.ssh og tryk Indtast.
Åbn kendte_værter fil med Notesblok.
Slet linjen, der forårsagede fejlen, og gem filen.

For at administrere nøgler korrekt, se vores guide vedr generere SSH-nøgler i Windows.

Mulighed 2: Brug af PuTTY

PuTTY gemmer nøgler i Windows-registreringsdatabasen i stedet for en fil.

Åbn registreringseditoren (Tryk Windows-tast + R, type regedit, og ramte Indtast).
Naviger til: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
Find den post, der matcher din servers værtsnavn eller IP.
Højreklik på det og vælg Slet.

Windows PowerShell-kommando fjerner SSH-værtsnøgle med File Explorer, der viser opdateret known_hosts-fil, og PuTTY Registry Editor, der viser slettebekræftelsesdialogen for værtsnøglen.

Løsning til Linux

De ssh-keygen kommando vi dækkede ind Metode 1 er standardmåden at løse dette på Linux. Det er hurtigt og naturligt understøttet.

Manuel redigering

Hvis du foretrækker at se filindholdet, kan du redigere det med en teksteditor som Nano.

Åbn din terminal.
Type nano ~/.ssh/kendte_værter og tryk Indtast.
Find linjenummeret nævnt i din fejlmeddelelse.
Slet linjen, og tryk derefter på Ctrl + X og Y at gemme.

Du kan også bruge Vim (vim ~/.ssh/kendte_værter), hvis du er bekendt med det.

Linux-terminal, der viser ssh-keygen-kommandoer til at fjerne SSH-værtsnøgler efter værtsnavn og IP-adresse, med succesbekræftelse og eksempler på kendte_værter.
En advarsel om deaktivering af checks

Du kan tvinge SSH til at oprette forbindelse uden bekræftelse, men det er risikabelt. Det omgår beskyttelsen mod man-in-the-middle-angreb.

Brug kun denne tilgang til lokal test på betroede netværk. For macOS og Linux, skriv dette:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]

Hvis du er på Windows, mislykkes Unix-stien. Du skal bruge NUL for at få bypasset til at fungere:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]

Kør ikke disse tilsidesættelser på offentlige forbindelser eller live-servere.

Reparation af nøgleuoverensstemmelser er rutinemæssig vedligeholdelse, men du kan gøre mere for at sikre din forbindelse. Bots målretter ofte standardport 22 med brute-force-angreb. Du kan undgå det meste af denne baggrundsstøj ved ændring af SSH-porte i Linux til noget mindre forudsigeligt.

Diagram over et mand-i-midten-angreb på SSH: angriber, der opsnapper klient-server-forbindelse, angribernøgle vs. servernøgle, datatyveri og økonomisk tab fremhævet.

Brug aldrig denne metode til produktionsservere eller over ikke-pålidelige netværk.

Sådan forhindrer du meddelelsen "Fjernværtsidentifikation er ændret" næste gang

Selvom du ikke altid kan forhindre lovlige værtsnøgleændringer, kan du minimere forstyrrelser og opretholde bedre sikkerhedspraksis.

Hurtig referencevejledning

Din rolle	Nøglestrategier
Systemadministratorer	Sikkerhedskopier nøgler, dokumentændringer, brug certifikater og roter nøgler regelmæssigt
Regelmæssige brugere	Vedligehold lagerbeholdning, verificer gennem sikre kanaler og overvåg logfiler
Cloud miljø Brugere	Brug DNS-navne, udnyt udbyderværktøjer og implementer infrastruktur som kode

Infografik, der viser bedste praksis for SSH-nøglestyring: Brug SSH-certifikater, DNS-navne, Infrastruktur som kode, sikkerhedskopier værtsnøgler, dokumentændringer og overvej bastion-værter.

Til systemadministratorer

Sikkerhedskopier værtsnøgler: Gem nøgler fra /etc/ssh/ før du geninstallerer OS. Gendan dem bagefter for at forhindre advarsler til dine brugere.

Dokument planlagte ændringer: Advar brugerne, før de skifter nøgler, og del de nye fingeraftryk sikkert. Dette giver dem mulighed for at bekræfte forbindelsen.

Brug SSH-certifikater: Store teams bør bruge en central certifikatmyndighed. Dette signerer værtsnøgler og fjerner behovet for manuel verifikation.

Implementer nøglerotation: Planlæg dine værtsnøgleændringer. Forudsigelige opdateringer er nemmere for dit team at håndtere end at overraske.

For almindelige brugere

Vedligehold en beholdning: Hold en personlig registrering af serverfingeraftryk, eller brug dit teams sikre dokumentation.

Bekræft via Out-of-Band: Bekræft nøgler mod en pålidelig kilde som cloud-konsollen, ikke tilfældige beskeder.

Overvåg logs: Tjek dine lokale SSH-logfiler regelmæssigt for mærkelige forbindelsesmønstre eller gentagne fejl.

Brug Config Management: Brug SSH-konfigurationsfiler til at håndtere dynamiske dev-miljøer uden at sænke sikkerhedsindstillingerne.

Til dynamiske skymiljøer

Brug DNS-navne: Opret forbindelse ved hjælp af værtsnavne i stedet for IP'er. Dette bevarer konsistensen, når den underliggende adresse ændres.

Udnyt Cloud-værktøjer: Brug udbyderkonsoller til at hente aktuelle fingeraftryk. Bekræft nøglerne mod disse værktøjer, før du accepterer ændringer.

Infrastruktur som kode: Automatiser nøglebekræftelse med værktøjer som Terraform. For avancerede opsætninger kan du også brug SSH SOCKS5 proxyer.

Bastion Værter: Konfigurer jump-servere med stabile nøgler. Disse fungerer som sikre indgangspunkter til din dynamiske infrastruktur.

Konklusion

"Advarsel: Fjernværtsidentifikation er ændret" fungerer som en vigtig sikkerhedsfunktion i SSH, ikke en fejl, der skal ignoreres. Selvom denne advarsel ofte vises af legitime årsager som servervedligeholdelse eller konfigurationsændringer, spiller den en nøglerolle i at beskytte dig mod man-in-the-middle-angreb og uautoriseret adgang.

Når du støder på denne advarsel, skal du kontrollere årsagen, før du fortsætter. I de fleste tilfælde er løsningen ligetil: Fjern den gamle værtsnøgle ved hjælp af de metoder, der er beskrevet for dit operativsystem, og accepter derefter den nye nøgle på din næste forbindelse.

Ved at lære, hvordan SSH-værtsnøgler fungerer, og følge bedste praksis, kan du opretholde både sikkerhed og bekvemmelighed i dine fjernadgangsarbejdsgange. For mere om sikker overførsel af filer, se kopiering af filer over SSH.

FAQ

Skal jeg tage advarslen: Fjernværtsidentifikation har ændret sig alvorligt?

Ja, tag det seriøst. Det betyder, at serverens identitet er ændret, hvilket kan signalere et man-in-the-middle-angreb eller blot rutinemæssig vedligeholdelse. Bekræft altid ændringen med din administrator eller udbyder, før du accepterer den nye nøgle for at sikre sikkerheden.

Hvad forårsager advarslen: Fjernværtsidentifikation er ændret?

Denne advarsel sker, når serverens aktuelle fingeraftryk ikke stemmer overens med det i din known_hosts-fil. Almindelige årsager omfatter OS-geninstallationer, IP-omfordelinger eller SSH-konfigurationsnulstillinger. I sjældne tilfælde indikerer det en aktiv man-in-the-middle-angrebsaflytning.

Kan denne fejl opstå på forskellige operativsystemer?

Ja, denne advarsel påvirker alle operativsystemer, der bruger SSH, inklusive Windows, macOS og Linux. Det stammer fra SSH-protokollens sikkerhedsverifikation. Selvom rettelsesmetoder varierer fra platform til platform, forbliver den underliggende sikkerhedsudløser identisk på tværs af hvert system.

Hvordan ved jeg, om værtsnøgleændringen er legitim eller et angreb?

For at bekræfte legitimiteten skal du tjekke for nylig vedligeholdelse, OS-opdateringer eller IP-ændringer. Du skal verificere det nye fingeraftryk mod en pålidelig kilde, såsom din cloududbyders konsol eller en bekræftelse fra din systemadministrator, før du opretter forbindelse.

Vil deaktivering af værtsnøglekontrol gøre SSH mere praktisk?

Det tilføjer bekvemmelighed, men fjerner sikkerhed. Deaktivering af kontroller dræber beskyttelsen mod man-in-the-middle-angreb, hvilket efterlader forbindelser sårbare. Du bør kun bruge denne indstilling i isolerede testmiljøer, aldrig på produktionsservere eller offentlige netværk, der involverer følsomme data.

Hvor ofte skal SSH-værtsnøgler ændres?

Værtsnøgler kræver generelt ikke regelmæssig rotation. Du bør typisk kun ændre dem efter en servergenopbygning, OS-geninstallation eller sikkerhedskompromittering. Hyppige ændringer forstyrrer brugerne, så prioriter stabilitet og klar kommunikation, når opdateringer er nødvendige.