SSH er en sikker netværksprotokol, der opretter en krypteret tunnel mellem systemer. Den forbliver populær blandt udviklere, der har brug for fjernadgang til computere uden at kræve en grafisk brugerflade. Selvom SSH har været omkring i årtier og har tjent utallige brugere pålideligt, kan det stadig påvirkes af visse fejl.
Mange af disse fejl er blevet kendt i SSH-fællesskabet, og deres løsninger er bredt dokumenteret. Disse omfatter firewall-inkompatibilitet, SSH public key injection-problemer, SSH file key mode-problemer, og fejlen 'Warning: Remote Host Identification Has Changed'.
Denne fejl optræder på alle større operativsystemer, herunder Windows, Linux og macOS. Kilden til problemet kan være en legitim sikkerhedsbetænkelighed snarere end en simpel teknisk fejl. I denne artikel forklarer vi, hvorfor dette sker, hvad det betyder for din SSH-forbindelses sikkerhed, og hvordan du løser det på hver større platform.
Hvad udløser advarslen 'Warning: Remote Host Identification Has Changed' (og skal du være bekymret?)
Advarslen 'Warning: Remote Host Identification Has Changed' vises, når SSH public key, der er gemt på din known_hosts fil, ikke stemmer overens med den nøgle, som serveren i øjeblikket præsenterer. Dette mismatch udløser SSH's indbyggede sikkerhedsmekanisme for at beskytte dig mod potentielle trusler.
Legitime grunde til værtskey-ændringer
Flere uskyldige grunde forklarer, hvorfor en servers værtskey kan ændres. Nogle gange vil du se variationer som 'RSA host key has changed', afhængig af den specifikke nøgletype, der bruges.
Serverrelaterede ændringer:
- Serveroperativsystemet blev geninstalleret eller opgraderet
- Serveren blev genopbygget eller gendannet fra backup
- Serverens SSH-konfiguration blev nulstillet
- Den fysiske eller virtuelle maskine blev erstattet
- Servermigrering til nyt hardware
Netværkskonfigurationsændringer:
- Cloud-udbydere genbruger IP-adresser over tid, eller din forbindelse går gennem en belastningsfordeler.
- DHCP tildelte en IP-adresse til en anden maskine
- En afviklet servers IP-adresse blev tildelt et nyt system
- DNS-poster blev opdateret til at pege på en anden server
Nøglestyringshandlinger:
- Systemadministratorer regenererede manuelt værtsnøgler af sikkerhedsmæssige årsager
- SSH-serversoftware blev geninstalleret
- Sikkerhedspolitikker krævede nøglerotation
Det er vigtigt at erkende, at ændringer af brugeradgangskoder ikke påvirker værtsnøgler. Disse repræsenterer separate autentiseringsmekanismer. Værtsnøgler ændres kun, når serveren selv eller dens SSH-konfiguration ændres.
Hvornår skal du tage advarslen alvorligt
Selvom mange værtsnøgleændringer er legitime, kunne dette indikere en ægte sikkerhedstrussel. Du bør være bekymret, hvis:
- Du ikke har foretaget nogen ændringer på serveren eller kender til nogen planlagt vedligeholdelse
- Du ikke kan bekræfte årsagen til nøgleændringen hos serveradministratoren
- Serveren tilgås via offentlige netværk eller upålidelige forbindelser
- Du forbinder til produktionssystemer eller servere med sensitive data
Man-in-the-middle-angreb er relativt sjældne, men de forekommer. I sådanne angreb positionerer en angriber sig mellem din computer og den legitime server og opfanger al trafik.
Menneskelig fejl og social engineering tegner sig for 68% af sikkerhedsbrud, hvilket gør årvågenhed vigtig. Du kan beskytte dine systemer yderligere ved at lære om forebyggelse af brute-force-angreb.
Nylige statistikker fra IBM viser, at omkostningerne ved et databrud globalt gennemsnitligt var 4,44 millioner dollars i 2025, med gennemsnitlige opdagelsestider på otte måneder. Det viser, hvorfor SSH's mekanisme til verifikation af værtsnøgler findes, og hvorfor du aldrig bør ignorere disse advarsler uden at undersøge dem.
Sådan verificeres det, om advarslen er sikker
Før du går i gang med at løse problemet, skal du foretage disse verifikationstrin:
- Spørg dit team: Hvis du deler serveradgang, skal du spørge kollegerne, om de har foretaget ændringer
- Gennemse serverlogfiler: Tjek vedligeholdelsesoversigter eller ændringslogfiler for seneste aktivitet
- Kontakt din hostingudbyder: Hvis du bruger cloudtjenester, skal du verificere, om vedligehold er udført
- Brug en sikker kanal: Hvis det er muligt, skal du oprette forbindelse via et kendt sikkert netværk for at verificere fingerprint'et
- Sammenlign fingeraftryk: Nogle hostingudbydere viser aktuelle SSH-fingerprints i deres kontrolpaneler
Hvis du kan bekræfte, at nøgleændringen var legitim, kan du sikkert fortsætte med at fjerne den gamle nøgle og acceptere den nye.
Hvis du vil undgå dynamisk IP-gentildeling eller værtsnygle-konflikter, spiller den infrastruktur, du vælger, en stor rolle.
Cloudzy leverer SSH VPS-hosting med dedikerede statiske IP-adresser. Du kører på AMD Ryzen 9-processorer med NVMe-lagring til øjeblikkelig kommandokørsel. Vores netværk når 40 Gbps på tværs af 12 globale lokationer. Plus, vi inkluderer gratis DDoS-beskyttelse for at holde din forbindelse sikker.
Sådan løses fejlen "Remote Host Identification Has Changed"
Løsningen er simpel: fjern den gamle nøglepost fra dit system. Dette fjerner uoverensstemmelsen og lader dig gemme den nye nøgle næste gang du forbinder. Se vores guide om SSH-klienter for flere værktøjer.
Du kan også gøre dette med en enkelt kommando eller ved at redigere filen manuelt.
Metode 1: Kommandolinjen (hurtigst)
Denne metode fungerer for macOS, Linux og Windows 10+ (ved hjælp af OpenSSH). Det er den hurtigste måde at løse fejlen på. Hvis du vil have mere information, kan du læse ssh-keygen man-side.
- Åbn terminalen.
- Kør denne kommando (erstat hostname med din servers IP-adresse eller domæne):
ssh-keygen -R hostnameHvis du foretrækker en visuel editor, kan du slette nøglen selv. Fejlbeskeden fortæller dig normalt præcis hvilket linjenummer du skal fjerne.
Åbn terminalen og rediger filen med Nano:
nano ~/.ssh/known_hosts
Find linjen fra fejlbeskeden. Slet den, og tryk derefter på Ctrl + X og Y at gemme.
Løsning for Windows
Windows-brugere anvender 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 den gennem Indstillinger > Apps > Valgfrie funktioner. Server 2025 indeholder klienten, men du skal aktivere den.
Hvis du bruger PowerShell eller Kommandoprompt, fungerer ssh-keygen kommandoen fra Metode 1 også her.
Hvis du i stedet vil redigere filen manuelt:
- Tryk Windows-tast + R.
- Type %USERPROFILE%\.ssh og tryk Enter.
- Åbn known_hosts filen med Notepad.
- Slet linjen, der forårsager fejlen, og gem filen.
Se vores vejledning om oprettelse af SSH-nøgler i Windows.
Mulighed 2: Brug af PuTTY
PuTTY gemmer nøgler i Windows Registry i stedet for i en fil.
- Åbn Registereditor (tryk på Windows-tast + R, skriv regeditog tryk Enter).
- Gå til: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
- Find det entry, der matcher din servers hostname eller IP-adresse.
- Højreklik på den og vælg Slet.
Løsning til Linux
Det ssh-keygen kommando, som vi gennemgik Metode 1 er standardmetoden til at løse dette på Linux. Det er hurtigt og har indbygget support.
Manuel redigering
Hvis du foretrækker at se filindholdet, kan du redigere det med et tekstredigeringsprogram som Nano.
- Åbn terminalen.
- Type nano ~/.ssh/known_hosts og tryk Enter.
- Find det linjenummer, der er nævnt i din fejlmeddelelse.
- Slet linjen og tryk derefter Ctrl + X og Y at gemme.
Du kan også bruge Vim (vim ~/.ssh/known_hosts) hvis du kender det.
Advarsel om deaktivering af kontroller
Du kan tvinge SSH til at forbinde uden verifikation, men det er risikabelt. Det omgår beskyttelsen mod man-in-the-middle-angreb.
Brug kun denne tilgang til lokal test på netværk, du har tillid til. For macOS og Linux, skal du skrive:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]Hvis du bruger Windows, mislykkes Unix-stien. Du skal bruge NUL sådan får du bypass'en til at fungere:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]Kør ikke disse tilsidesættelser på offentlige forbindelser eller live-servere.
At rette nøgleuoverensstemmelser er almindelig vedligeholdelse, men du kan gøre mere for at sikre forbindelsen. Bots angriber ofte standardport 22 med brute-force-angreb. Du kan undgå det meste af denne baggrundsstøj ved at ændring af SSH-porte i Linux til noget mindre forudsigeligt.
Brug aldrig denne metode på produktionsservere eller over upålidelige netværk.
Sådan forhindrer du "Remote Host Identification Has Changed"-meddelelsen næste gang
Du kan ikke altid forhindre legitime ændringer af værtsnøgler, men du kan minimere nedetid og vedligeholde bedre sikkerhedspraksis.
Hurtig referenceGuide
| Din rolle | Vigtige strategier |
| Systemadministratorer | Sikkerhedskopiér nøgler, dokumentér ændringer, brug certifikater og rotér nøgler regelmæssigt |
| Almindelige brugere | Vedligehold inventar, bekræft via sikre kanaler og overvåg logs |
| Cloud-miljø
Brugere |
Brug DNS-navne, anvend providerværktøjer og implementér infrastruktur som kode |
For systemadministratorer
Sikkerhedskopiér værtsnøgler: Gem nøgler fra /etc/ssh/ før du geninstallerer OS'et. Genskab dem bagefter for at undgå advarsler til dine brugere.
Dokumentér planlagte ændringer: Underret brugere før du ændrer nøgler og del de nye fingeraftryk sikkert. Dette giver dem mulighed for at bekræfte forbindelsen.
Brug SSH certifikater: Store hold bør bruge en central certifikatmyndighed. Den signerer værtsnøgler og fjerner behovet for manuel bekræftelse.
Implementér nøglerotation: Planlæg dine værtsnøgleskift. Forudsigelige opdateringer er lettere at håndtere end uventede.
For almindelige brugere
Vedligehold et lager: Vedligehold en personlig registrering af serverfingeraftryk eller brug dit holds sikre dokumentation.
Bekræft via alternativ kanal: Kontroller nøgler mod en troværdig kilde som cloudkonsollen, ikke tilfældige beskeder.
Overvåg logs: Tjek dine lokale SSH-logs regelmæssigt for mærkelige forbindelsesmønstre eller gentagne fejl.
Brug konfigurationsstyring: Brug SSH-konfigurationsfiler til at håndtere dynamiske udviklingmiljøer uden at reducere sikkerhedsindstillingerne.
For dynamiske cloudmiljøer
Brug DNS-navne: Forbind ved hjælp af værtsnavne i stedet for IP-adresser. Dette opretholder konsistens når den underliggende adresse ændres.
Anvend cloudværktøjer: Brug leverandørkonsoller til at hente aktuelle fingeraftryk. Verificer nøgler mod disse værktøjer, før du accepterer ændringer.
Infrastruktur som kode: Automatisér nøgleverifikation med værktøjer som Terraform. For avancerede opsætninger kan du også bruge SSH SOCKS5-proxyer.
Bastion-værter: Konfigurer jumpservere med stabile nøgler. De fungerer som sikre adgangspunkter til din dynamiske infrastruktur.
Konklusion
Advarslen "Warning: Remote Host Identification Has Changed" er en vigtig sikkerhedsfunktion i SSH, ikke en fejl, der bør ignoreres. Selvom denne advarsel ofte vises for legitime årsager som servervedligeholdelse eller konfigurationsændringer, spiller den en nøglerolle i beskyttelsen mod man-in-the-middle-angreb og uautoriseret adgang.
Når du støder på denne advarsel, skal du verificere å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 metoderne beskrevet for dit operativsystem, og accepter derefter den nye nøgle ved din næste forbindelse.
Ved at lære, hvordan SSH-værtsnøgler fungerer, og ved at følge best practices, kan du opretholde både sikkerhed og bekvemmelighed i dine fjernforbindelsesarbejdsgange. Læs mere om sikker filoverførsel på kopiering af filer over SSH.
