SSH-nøkkel i Linux: sikker innlogging i 10 steg [2026]

Passord lekker, gjettes og gjenbrukes. En SSH-nøkkel gjør ingen av delene. Når du logger inn med nøkkel, forlater den hemmelige delen aldri maskinen din, og serveren slipper å lagre noe den kan miste. Denne veiledningen tar deg gjennom hele oppsettet i ti konkrete steg, fra du genererer din første Ed25519-nøkkel til du har stengt passordinnlogging helt på serveren. Du trenger rundt 30 minutter og en server du har tilgang til.

Alt under er testet på Ubuntu og fungerer likt på Debian, Fedora og de fleste Linux-distribusjoner. Vi dekker også macOS og Windows, slik at samme nøkkelpar fungerer uansett hvor du sitter. Hvert steg har faktiske kommandoer, eksempler på utdata du bør se, og en feilsøkingsdel for når noe ikke stemmer.

Hva er en SSH-nøkkel, og hvorfor slår den passordet

En SSH-nøkkel er et par av matematisk koblede filer: en privat nøkkel som blir på din maskin, og en offentlig nøkkel du legger på serveren. Den private nøkkelen er en hemmelighet bare du har. Den offentlige kan deles fritt, akkurat som adressen din. Når du kobler til, sender serveren en utfordring. Klienten din signerer utfordringen med den private nøkkelen, og serveren verifiserer signaturen med din offentlige nøkkel. Den private nøkkelen sendes aldri over nettverket. Dette er en digital signatur i praksis, og det er grunnen til at avlytting ikke hjelper en angriper.

Forskjellen fra passord er fundamental. Et passord på 12 tegn kan brute-forces, fanges av en keylogger eller fiskes ut via phishing. En Ed25519-nøkkel gir rundt 128 bits sikkerhet, som ingen klarer å gjette seg gjennom. Fordi serveren bare lagrer den offentlige nøkkelen, gir en lekkasje av serverens filer ingen angriper noe de kan logge inn med. Selv om noen kopierer den offentlige nøkkelen din, kan de ikke regne seg tilbake til den private.

SSH bygger på asymmetrisk kryptografi, den samme familien som beskytter HTTPS og TLS. Ed25519 bruker Curve25519, en elliptisk kurve som gir høy sikkerhet med svært små nøkler. En privat Ed25519-nøkkel er bare 256 bit, mens en RSA-nøkkel med tilsvarende styrke krever tusenvis av bit. Mindre nøkler betyr raskere signering, raskere verifisering og kortere offentlige nøkler som er enklere å håndtere.

Nøkkelinnlogging er også grunnmuren for automatisering. Skript, sikkerhetskopier, distribusjon og verktøy som Ansible eller rsync logger inn uten å skrive passord. Når du først har satt opp nøkler riktig, blir alt dette tryggere og enklere på samme tid. Det er sjelden en avveiing mellom sikkerhet og bekvemmelighet er så ensidig i din favør.

Forutsetninger: dette trenger du før du starter

Du trenger lite for å komme i gang, men versjonene betyr noe. OpenSSH har endret seg mye de siste årene, og enkelte funksjoner i denne veiledningen krever nyere klienter. Sjekk hva du har før du går videre.

En lokal maskin med Linux, macOS eller Windows 10/11. OpenSSH-klienten følger med alle tre.
OpenSSH 8.2 eller nyere hvis du vil bruke maskinvarenøkler (FIDO2). OpenSSH 9.x og 10 anbefales for post-kvante nøkkelutveksling.
En server du har konto på, med SSH-tjenesten aktiv. Ubuntu 22.04 LTS eller 24.04 LTS fungerer rett ut av boksen.
Et brukernavn og en eksisterende innloggingsmetode (passord eller eksisterende nøkkel) for det første oppsettet.
Administratortilgang (sudo) på serveren hvis du skal herde sshd_config i de siste stegene.

Bekreft OpenSSH-versjonen din med kommandoen under. Tallet etter «OpenSSH_» er det som teller. Er det 8.2 eller høyere, er du klar for alt i denne veiledningen.

$ ssh -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024

Ser du ikke noe svar på Windows, mangler OpenSSH-klienten. Den installeres under Innstillinger, Apper, Valgfrie funksjoner, OpenSSH-klient. På Linux installerer du den med sudo apt install openssh-client, og serverdelen med sudo apt install openssh-server. Etter det er du klar for steg 1.

Steg 1: Sjekk om du allerede har SSH-nøkler

Mange har allerede et nøkkelpar uten å vite det, fordi verktøy som GitHub Desktop eller en tidligere installasjon kan ha laget ett. Du vil ikke overskrive en nøkkel som er i bruk andre steder, så start med å se etter eksisterende filer. Alle nøkler ligger i mappen ~/.ssh i hjemmekatalogen din.

$ ls -la ~/.ssh
total 28
drwx------  2 sam sam 4096 jun 13 09:14 .
drwxr-xr-x 45 sam sam 4096 jun 13 09:10 ..
-rw-------  1 sam sam  411 jun 13 09:14 id_ed25519
-rw-r--r--  1 sam sam   96 jun 13 09:14 id_ed25519.pub
-rw-r--r--  1 sam sam  142 jun 13 09:12 known_hosts

Ser du filer som id_ed25519, id_rsa eller id_ecdsa sammen med en .pub-versjon, har du allerede et nøkkelpar. Filer uten .pub er private og skal aldri deles. Den med .pub er den offentlige. Får du «No such file or directory», finnes ikke mappen ennå, og du har ingen nøkler. Begge deler er helt greit.

Vil du gjenbruke en eksisterende Ed25519-nøkkel, kan du hoppe rett til steg 4. Har du bare en gammel RSA- eller ECDSA-nøkkel, anbefaler vi at du lager en ny Ed25519-nøkkel uansett. Det tar et halvt minutt, og du får en moderne og raskere nøkkel. Du kan beholde begge samtidig, fordi SSH prøver flere nøkler automatisk.

Finnes ikke mappen, lager du den med riktige rettigheter med en gang. Mappen skal kun være tilgjengelig for deg, ellers nekter OpenSSH å bruke nøklene av sikkerhetshensyn.

$ mkdir -p ~/.ssh
$ chmod 700 ~/.ssh

Steg 2: Generer en Ed25519-nøkkel med ssh-keygen

Nå lager du selve nøkkelparet. Kommandoen ssh-keygen følger med OpenSSH og gjør alt. Vi bruker Ed25519, som er det anbefalte valget for nye nøkler. Flagget -a 100 setter antall runder i nøkkelderiveringsfunksjonen som beskytter den private nøkkelen på disk, og -C legger til en kommentar som hjelper deg å kjenne igjen nøkkelen senere.

$ ssh-keygen -t ed25519 -a 100 -C "sam@laptop-2026"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/sam/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sam/.ssh/id_ed25519
Your public key has been saved in /home/sam/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:8Xq2pV0p9k3mB7nLwR4tY1cZsD6fH8jK2mN4oP6qR8s sam@laptop-2026

Trykk Enter på det første spørsmålet for å godta standardplasseringen ~/.ssh/id_ed25519. På spørsmålet om passordfrase bør du skrive inn en god frase. Dette er viktig: passordfrasen krypterer den private nøkkelen på disk, slik at en stjålet laptop ikke gir noen tilgang til serverne dine. Du slipper å skrive den hver gang når du senere setter opp ssh-agent i steg 6.

Trenger du en RSA-nøkkel for et eldre system som ikke støtter Ed25519, bruker du denne varianten i stedet. Bruk minst 4096 bit. Aldri lavere enn 3072.

$ ssh-keygen -t rsa -b 4096 -a 100 -C "sam@laptop-2026-rsa"

Fingeravtrykket (SHA256-strengen) er en kort identifikator for nøkkelen, avledet med en SHA-256-hash av den offentlige nøkkelen. Du bruker det til å bekrefte at du faktisk snakker med riktig nøkkel når du legger den på en server eller deler den med en kollega. Tabellen under forklarer de viktigste flaggene til ssh-keygen.

Flagg	Hva det gjør	Anbefalt verdi
`-t`	Velger nøkkeltype (algoritme)	`ed25519`
`-b`	Antall bit (kun relevant for RSA)	`4096` for RSA
`-a`	Runder i KDF som beskytter privatnøkkelen	`100`
`-C`	Kommentar for å identifisere nøkkelen	e-post eller maskinnavn
`-f`	Filsti for nøkkelen	standard, eller egendefinert navn

Steg 3: Forstå nøkkelfilene og sett riktige rettigheter

Etter generering har du to filer. Den private nøkkelen heter id_ed25519 uten filendelse, og den offentlige heter id_ed25519.pub. Den private er hemmeligheten din og må aldri kopieres til en server, sendes på e-post eller lastes opp noe sted. Den offentlige kan du dele fritt. Se på innholdet i den offentlige nøkkelen med cat.

$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH8k2pV0p9k3mB7nLwR4tY1cZsD6fH8jK2mN4oP6qR8s sam@laptop-2026

Linjen har tre deler: algoritmen (ssh-ed25519), selve nøkkelen i base64, og kommentaren din til slutt. Det er nettopp denne linjen du skal legge på serveren i neste steg. Den private nøkkelen ser du helst ikke på, men den begynner med -----BEGIN OPENSSH PRIVATE KEY----- og er kryptert hvis du satte en passordfrase.

Rettighetene må være strenge, ellers nekter OpenSSH å bruke nøklene. Dette er en av de vanligste feilkildene. Den private nøkkelen skal bare være lesbar for deg (600), og selve mappen skal være 700. Sett dem eksplisitt for å være sikker.

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ed25519
$ chmod 644 ~/.ssh/id_ed25519.pub
$ ls -l ~/.ssh/id_ed25519
-rw------- 1 sam sam 411 jun 13 09:14 /home/sam/.ssh/id_ed25519

Får du senere meldingen «UNPROTECTED PRIVATE KEY FILE!» når du logger inn, er det fordi rettighetene er for åpne. Da kjører du chmod 600 på den private nøkkelen igjen. Den samme regelen gjelder på serveren: mappen ~/.ssh og filen authorized_keys der må også ha riktige rettigheter, noe vi kommer tilbake til i feilsøkingsdelen.

Steg 4: Kopier den offentlige nøkkelen til serveren

Nå skal den offentlige nøkkelen din inn i filen ~/.ssh/authorized_keys på serveren. Enhver nøkkel som står oppført der, får logge inn som den brukeren. Den enkleste måten er verktøyet ssh-copy-id, som gjør alt riktig for deg, inkludert rettigheter. Erstatt brukernavn og serveradresse med dine egne.

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/sam/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)
[email protected]'s password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

Du skriver inn serverpassordet ditt denne ene gangen. Etterpå er nøkkelen på plass, og du trenger aldri passordet igjen. Har du ikke ssh-copy-id (det mangler på Windows og enkelte minimale systemer), kan du gjøre det samme manuelt med en enkelt kommando. Den legger nøkkelen til uten å overskrive eksisterende nøkler.

$ cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

På Windows med PowerShell ser den manuelle varianten litt annerledes ut, fordi cat heter type der. Bruk denne i stedet hvis du sitter på Windows uten ssh-copy-id.

PS> type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "cat >> .ssh/authorized_keys"

Verifiser at nøkkelen havnet riktig sted ved å logge inn og se på filen. Du skal se nøyaktig den samme linjen som cat ~/.ssh/id_ed25519.pub ga deg lokalt. Står den der, er du klar til å teste innloggingen i neste steg.

Steg 5: Logg inn med nøkkel og bekreft at det virker

Test innloggingen. Hvis alt stemmer, skal du komme rett inn uten å bli spurt om serverpassordet. Blir du spurt om passordfrasen til nøkkelen, er det bra, det betyr at nøkkelen brukes. Det er passordfrasen til den private nøkkelen, ikke serverpassordet.

$ ssh [email protected]
Enter passphrase for key '/home/sam/.ssh/id_ed25519':
Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-41-generic x86_64)
Last login: Fri Jun 13 09:02:11 2026 from 192.0.2.10
sam@server:~$

Vil du se nøyaktig hva som skjer, kjør med -v for detaljert utdata. Dette er uvurderlig for feilsøking. Du leter etter linjer som «Offering public key» og «Server accepts key», som bekrefter at nøkkelen ble tilbudt og godtatt.

$ ssh -v [email protected] 2>&1 | grep -i "key\|auth"
debug1: Offering public key: /home/sam/.ssh/id_ed25519 ED25519 SHA256:8Xq2pV0...
debug1: Server accepts key: /home/sam/.ssh/id_ed25519 ED25519 SHA256:8Xq2pV0...
debug1: Authentication succeeded (publickey).

Kommer du fortsatt inn med passord i stedet for nøkkel, er noe galt. De vanligste årsakene er feil rettigheter på ~/.ssh eller authorized_keys på serveren, at nøkkelen ikke havnet i riktig brukers hjemmekatalog, eller at serveren har slått av PubkeyAuthentication. Feilsøkingsdelen lenger ned går gjennom hver av disse. Ikke gå videre til å stenge passordinnlogging før nøkkelinnloggingen fungerer pålitelig.

Når dette virker, har du oppnådd det viktigste: en innlogging som ikke kan phishes, ikke kan gjettes og ikke lekker fra serveren. Resten av stegene gjør hverdagen smidigere og strammer til sikkerheten ytterligere.

Steg 6: Bruk ssh-agent så du slipper å skrive passordfrasen

En god passordfrase er bra for sikkerheten, men irriterende å skrive hver gang. Løsningen er ssh-agent, et lite program som holder den dekrypterte nøkkelen i minnet i økten din. Du skriver passordfrasen én gang, og agenten håndterer resten. Nøkkelen ligger aldri på disk i dekryptert form.

$ eval "$(ssh-agent -s)"
Agent pid 4711
$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/sam/.ssh/id_ed25519:
Identity added: /home/sam/.ssh/id_ed25519 (sam@laptop-2026)
$ ssh-add -l
256 SHA256:8Xq2pV0p9k3mB7nLwR4tY1cZsD6fH8jK2mN4oP6qR8s sam@laptop-2026 (ED25519)

Etter dette logger du inn uten å bli spurt om noe. På de fleste Linux-skrivebord og på macOS startes agenten automatisk ved innlogging. På macOS kan du lagre passordfrasen i nøkkelringen med ssh-add --apple-use-keychain ~/.ssh/id_ed25519, slik at den huskes mellom omstarter.

På Windows kjører ssh-agent som en tjeneste. Du aktiverer den og legger til nøkkelen slik. Tjenesten starter da automatisk ved hver oppstart.

PS> Get-Service ssh-agent | Set-Service -StartupType Automatic
PS> Start-Service ssh-agent
PS> ssh-add $env:USERPROFILE\.ssh\id_ed25519

Et viktig sikkerhetsråd: vær forsiktig med videresending av agenten (ssh -A). Når du videresender agenten til en server, kan root på den serveren bruke nøklene dine til å logge inn andre steder så lenge du er tilkoblet. Bruk det bare mot servere du stoler fullt på, og vurder ssh -J (jump host) i stedet. For de fleste er det tryggest å la videresending være av.

Steg 7: Sett opp ~/.ssh/config for enklere innlogging

Å skrive ssh [email protected] -p 2222 -i ~/.ssh/id_ed25519 hver gang er tungvint. En konfigurasjonsfil lar deg gi serveren et kallenavn og samle alle innstillinger ett sted. Opprett filen ~/.ssh/config og legg inn en blokk per server.

# ~/.ssh/config
Host produksjon
    HostName 192.0.2.50
    User sam
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host *.intern.example.no
    User drift
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent no

Etter dette logger du inn med bare ssh produksjon. Innstillingen IdentitiesOnly yes er nyttig: den tvinger SSH til å bruke kun nøkkelen du har oppgitt, i stedet for å prøve alle nøkler i agenten. Det forhindrer at du ved et uhell låser ut en konto fordi serveren teller for mange mislykkede forsøk.

Sett rettighetene på config-filen til 600, akkurat som for nøklene. Mønstre med jokertegn (*) gjør at du kan sette felles innstillinger for hele domener. Rekkefølgen teller: SSH bruker den første verdien som matcher for hver innstilling, så legg de mest spesifikke blokkene øverst.

$ chmod 600 ~/.ssh/config
$ ssh produksjon
sam@server:~$

Config-filen er også stedet du setter opp jump hosts for å nå servere bak en bastion, med ProxyJump bastion. For team som forvalter mange maskiner, blir denne filen raskt det viktigste verktøyet for å holde orden. Den deles trygt i et internt repo så lenge den ikke inneholder hemmeligheter, og det gjør den ikke: bare oppsett og filstier.

Steg 8: Herd SSH-serveren i sshd_config

Nå som nøkkelinnlogging fungerer, kan du stenge de svake metodene. Dette er det steget som faktisk hever sikkerheten på serveren. Rediger /etc/ssh/sshd_config med sudo, og endre eller legg til linjene under. Gjør dette mens du fortsatt har en åpen, fungerende SSH-økt, så du ikke låser deg selv ute.

# /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
UsePAM yes
MaxAuthTries 3
LoginGraceTime 20

De viktigste linjene er PasswordAuthentication no, som slår av passordinnlogging helt, og PermitRootLogin prohibit-password, som tillater root bare med nøkkel (eller no for å forby root-innlogging fullstendig). Tabellen forklarer hver direktiv. Etter endringen tester du konfigurasjonen før du laster den inn på nytt.

Direktiv	Anbefalt verdi	Effekt
`PasswordAuthentication`	`no`	Stenger passordinnlogging helt
`PubkeyAuthentication`	`yes`	Tillater nøkkelinnlogging
`PermitRootLogin`	`prohibit-password`	Root bare med nøkkel, aldri passord
`MaxAuthTries`	`3`	Begrenser forsøk per tilkobling
`LoginGraceTime`	`20`	Kort vindu før uautentisert økt lukkes

$ sudo sshd -t        # tester syntaksen, ingen utdata betyr OK
$ sudo systemctl reload ssh
$ # IKKE lukk den eksisterende okten. Apne et NYTT vindu og test:
$ ssh produksjon
sam@server:~$

Den gylne regelen: behold den gamle økten åpen til du har bekreftet i et nytt vindu at innlogging fortsatt fungerer. Klarer du ikke logge inn på nytt, kan du rette feilen i den åpne økten. Når den nye innloggingen fungerer, er serveren herdet, og passordbaserte angrep er fjernet som trussel. NSMs grunnprinsipper for IKT-sikkerhet anbefaler nettopp å fjerne passordbasert fjerntilgang til fordel for nøkler eller flerfaktor.

Steg 9: SSH-nøkler på macOS og Windows

macOS

macOS har OpenSSH innebygd, og alle kommandoene over fungerer identisk i Terminal. Det eneste tillegget verdt å kjenne er integrasjonen med nøkkelringen. Når du legger til nøkkelen med flagget for nøkkelring, husker macOS passordfrasen mellom omstarter, slik at du aldri trenger å skrive den manuelt.

$ ssh-keygen -t ed25519 -a 100 -C "sam@mac-2026"
$ ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Legg til linjene UseKeychain yes og AddKeysToAgent yes under en Host *-blokk i ~/.ssh/config, så lastes nøkkelen automatisk ved første bruk. Da har du samme sømløse opplevelse som på Linux.

Windows 10 og 11

Windows har hatt OpenSSH innebygd siden Windows 10. Du kjører ssh-keygen i PowerShell eller Terminal nøyaktig som på Linux. Nøklene havner i mappen .ssh under brukerprofilen din. Den eneste forskjellen er at ssh-agent kjører som en Windows-tjeneste, som vist i steg 6.

PS> ssh-keygen -t ed25519 -a 100 -C "sam@win-2026"
PS> Get-Service ssh-agent | Set-Service -StartupType Automatic
PS> Start-Service ssh-agent
PS> ssh-add $env:USERPROFILE\.ssh\id_ed25519

En vanlig snublestein på Windows er rettigheter på den private nøkkelfilen. Windows bruker ACL-er i stedet for Unix-rettigheter, og noen ganger arver filen for vide rettigheter. Får du «Bad permissions» eller «Permissions are too open», må du fjerne arvede rettigheter og gi kun din egen bruker tilgang. Det gjøres enklest via Egenskaper, Sikkerhet, Avansert på filen, eller med icacls i PowerShell.

Steg 10: Maskinvarenøkler (FIDO2) og post-kvante

For maksimal sikkerhet kan du binde SSH-nøkkelen til en fysisk sikkerhetsnøkkel som en YubiKey. Da kreves det at du har den fysiske enheten og berører den for å logge inn. Selv om noen stjeler både laptopen og passordfrasen, kommer de ingen vei uten den fysiske nøkkelen. OpenSSH har støttet dette siden versjon 8.2 gjennom nøkkeltypene ed25519-sk og ecdsa-sk (sk står for security key).

$ ssh-keygen -t ed25519-sk -O resident -O application=ssh:sam -C "sam@yubikey"
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
Enter file in which to save the key (/home/sam/.ssh/id_ed25519_sk):
Your identification has been saved in /home/sam/.ssh/id_ed25519_sk

Flagget -O resident lagrer en referanse på selve nøkkelen, slik at du kan hente den ned på en ny maskin med ssh-keygen -K. Den private delen forlater aldri maskinvaren. Du kopierer den offentlige .pub-filen til serveren akkurat som før, og logger inn ved å berøre nøkkelen.

På kvantefronten har OpenSSH allerede tatt grep. Fra OpenSSH 9 ble en hybrid nøkkelutveksling (sntrup761x25519-sha512) tatt i bruk, og OpenSSH 10, som ble gitt ut i 2025, fjernet den gamle DSA-algoritmen helt og bruker en post-kvante hybrid nøkkelutveksling (mlkem768x25519-sha256) som standard. Dette gjelder selve tunnelen, ikke autentiseringsnøkkelen din, men det betyr at trafikken din allerede er beskyttet mot fremtidig kvantedekryptering. Du trenger ikke gjøre noe ekstra for å få dette utover å holde OpenSSH oppdatert. Les mer i vår oversikt over kryptografi og digital tillit.

RSA vs Ed25519 vs ECDSA: hvilken nøkkeltype bør du velge

Valget av nøkkeltype er enkelt for de fleste: bruk Ed25519. Men det finnes situasjoner der du trenger noe annet, og det er greit å forstå hvorfor. Tabellen oppsummerer egenskapene til hver type slik de står i 2026.

Type	Sikkerhetsnivå	Nøkkelstørrelse	Hastighet	Anbefaling 2026
Ed25519	~128 bit	256 bit (liten)	Svært rask	Førstevalg for nye nøkler
RSA 4096	~128 bit	4096 bit (stor)	Tregere signering	Reserve for eldre systemer
RSA 3072	~112 bit	3072 bit	Middels	Minimum hvis RSA kreves
ECDSA	~128 bit	256 bit	Rask	Kun for kompatibilitet
DSA	For svak	1024 bit	Utdatert	Aldri, fjernet i OpenSSH 10

Ed25519 vinner på alle praktiske mål: liten, rask og uten de implementasjonsfellene som har plaget ECDSA. ECDSA er knyttet til NIST-kurver som mange foretrekker å unngå, og den er sårbar for feil i tilfeldighetsgeneratoren. RSA er fortsatt trygt med 4096 bit og har bredest kompatibilitet, så velg den hvis du møter et gammelt system som ikke forstår Ed25519. DSA er ute av bildet helt, fjernet fra OpenSSH 10 fordi 1024-bits nøkler ikke lenger gir forsvarlig sikkerhet.

Mozillas OpenSSH-retningslinjer og OpenSSH-prosjektets egen dokumentasjon peker begge på Ed25519 som standardvalget, med RSA 4096 som reserve. For en nybegynner er rådet derfor kort: lag en Ed25519-nøkkel, og bare bytt hvis et konkret system nekter å ta imot den.

5 vanlige fallgruver og hvordan du unngår dem

Feil rettigheter på filene. Den vanligste feilen. OpenSSH nekter å bruke en privat nøkkel som er lesbar for andre. Sett chmod 700 ~/.ssh og chmod 600 på den private nøkkelen og på authorized_keys, både lokalt og på serveren.
Ingen passordfrase på nøkkelen. En nøkkel uten passordfrase ligger ubeskyttet på disk. Stjeles maskinen, stjeles tilgangen til alle serverne dine. Sett alltid en passordfrase, og bruk ssh-agent for å slippe å skrive den hele tiden.
Å stenge passord før nøkkelen virker. Setter du PasswordAuthentication no før du har bekreftet nøkkelinnlogging, kan du låse deg selv ute. Test alltid i et nytt vindu mens den gamle økten er åpen.
Nøkkelen i feil brukers hjemmekatalog. authorized_keys må ligge i hjemmekatalogen til den brukeren du logger inn som. Legger du nøkkelen under root, men logger inn som sam, virker det ikke.
Å kopiere den private nøkkelen til serveren. Bare den offentlige .pub-filen skal på serveren. Legger du den private nøkkelen der, har du gitt bort hemmeligheten din. Kopier aldri filen uten .pub.

De fleste problemer i SSH-oppsett kommer ned til disse fem. Går du gjennom listen før du roper på hjelp, løser du som regel saken selv. Den neste delen gir deg presise kommandoer for å diagnostisere det som måtte gjenstå.

Feilsøking: 8 problemer og løsninger

Når noe ikke virker, er det nesten alltid en av disse åtte situasjonene. Start med å kjøre ssh -vvv for å se nøyaktig hvor det stopper. Tabellen under er en hurtigreferanse, og avsnittene utdyper de vanligste.

Feilmelding	Sannsynlig årsak	Løsning
Permission denied (publickey)	Nøkkel ikke godtatt	Sjekk authorized_keys og rettigheter
UNPROTECTED PRIVATE KEY FILE	For åpne rettigheter	`chmod 600` på privatnøkkelen
Connection refused	SSH-tjeneste nede eller feil port	Sjekk `systemctl status ssh`
Host key verification failed	Serverens nøkkel endret	Fjern gammel linje i known_hosts
Too many authentication failures	Agenten prøver for mange nøkler	Bruk `IdentitiesOnly yes`
Agent admitted failure	Nøkkel ikke i agenten	Kjør `ssh-add` på nytt
Could not resolve hostname	DNS- eller navnefeil	Sjekk adressen og config-filen
sign_and_send_pubkey error	Korrupt eller feil nøkkel	Verifiser med `ssh-keygen -y`

Permission denied (publickey)

Dette er den hyppigste feilen. Den betyr at serveren ikke godtok nøkkelen din. Sjekk tre ting på serveren: at ~/.ssh er 700, at ~/.ssh/authorized_keys er 600 og eid av riktig bruker, og at nøkkellinjen faktisk står i filen. Logg inn med passord (hvis fortsatt mulig) og kjør kommandoene under.

$ ls -ld ~/.ssh
drwx------ 2 sam sam 4096 jun 13 09:14 /home/sam/.ssh
$ ls -l ~/.ssh/authorized_keys
-rw------- 1 sam sam 96 jun 13 09:14 /home/sam/.ssh/authorized_keys
$ sudo tail -n 20 /var/log/auth.log | grep sshd

Loggen /var/log/auth.log (eller journalctl -u ssh på systemd) viser ofte den eksakte årsaken, for eksempel «Authentication refused: bad ownership or modes for directory». Det peker rett på et rettighetsproblem.

Host key verification failed

Denne dukker opp når serverens vertsnøkkel har endret seg, typisk etter en ny installasjon eller en IP-gjenbruk. SSH advarer fordi det også kan bety et angrep. Er du sikker på at endringen er legitim, fjerner du den gamle oppføringen og kobler til på nytt. Da lagres den nye nøkkelen.

$ ssh-keygen -R 192.0.2.50
# Host 192.0.2.50 found: line 3
/home/sam/.ssh/known_hosts updated.
$ ssh produksjon

Too many authentication failures

Har du mange nøkler i agenten, prøver SSH dem alle, og serveren kan lukke forbindelsen før den riktige nøkkelen kommer til. Løsningen er IdentitiesOnly yes i config-filen, som tvinger SSH til å bruke bare den oppgitte nøkkelen. Du kan også teste direkte fra kommandolinjen.

$ ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected]

Andre vanlige feil løser du raskt: «Connection refused» betyr som regel at SSH-tjenesten er nede eller lytter på en annen port, sjekk med sudo systemctl status ssh og sudo ss -tlnp | grep ssh. «Agent admitted failure» betyr at nøkkelen ikke er lastet i agenten, kjør ssh-add på nytt. Vil du bekrefte at en privat nøkkel er gyldig og hente den tilhørende offentlige delen, bruker du ssh-keygen -y -f ~/.ssh/id_ed25519.

known_hosts og vertsnøkler: verifiser serveren

SSH-nøkler beskytter deg mot at andre utgir seg for å være deg. Vertsnøkler beskytter deg mot at noen utgir seg for å være serveren. Første gang du kobler til en server, viser SSH serverens fingeravtrykk og spør om du stoler på det. Sier du ja, lagres nøkkelen i ~/.ssh/known_hosts, og fra da av sjekker SSH at serveren er den samme hver gang.

$ ssh [email protected]
The authenticity of host '192.0.2.50' can't be established.
ED25519 key fingerprint is SHA256:rT4kP9wL2mX8vB1nQ6cF3jH7sD0aG5yK4uE2oI9pN8s.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Her bør du ikke bare trykke ja blindt. Endres en vertsnøkkel uventet senere, kan det bety et man-in-the-middle-angrep. Den trygge måten er å hente serverens fingeravtrykk på forhånd, direkte på serveren, og sammenligne. Kjør kommandoen under på serveren og kontroller at strengen stemmer med den SSH viser deg.

$ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:rT4kP9wL2mX8vB1nQ6cF3jH7sD0aG5yK4uE2oI9pN8s root@server (ED25519)

Stemmer fingeravtrykkene, vet du at du snakker med riktig maskin. For flåter av servere kan du distribuere en ferdig known_hosts-fil til alle klienter, eller bruke SSH-sertifikater for vertsnøkler slik at klientene stoler på en CA i stedet for hver enkelt server. Det fjerner spørsmålet helt og hindrer at brukere venner seg til å trykke ja uten å tenke.

Avanserte tips for proffer

Når grunnoppsettet sitter, finnes det flere grep som skalerer og strammer til. Disse er verdt å kjenne når du forvalter mange servere eller et helt team.

Egne nøkler per formål. Lag separate nøkler for jobb, privat, GitHub og servere. Da kan du tilbakekalle én uten å påvirke resten. Pek på riktig nøkkel per Host i config-filen.
SSH-sertifikater i stedet for authorized_keys. Med en egen CA signerer du brukernøkler som er gyldige i et begrenset tidsrom. Servere stoler på CA-en, ikke på enkeltnøkler, så du slipper å oppdatere authorized_keys på hundrevis av maskiner.
Begrens nøkler i authorized_keys. Du kan prefiksere en nøkkel med from="192.0.2.0/24", command="..." eller no-port-forwarding for å låse en nøkkel til en bestemt kilde eller et bestemt skript. Nyttig for automatiserte sikkerhetskopier.
Jump hosts. Bruk ProxyJump bastion for å nå servere bak en bastion uten å eksponere dem direkte. Tryggere enn agentvideresending.
Roter nøkler jevnlig. Sett en rutine for å bytte nøkler, for eksempel årlig, og fjern gamle nøkler fra alle authorized_keys-filer. Et verktøy som Ansible gjør dette trivielt.

Kombiner dette med god grunnsikkerhet ellers. SSH-herding er ett lag, men en server trenger også brannmur, oppdateringer og overvåking. For organisasjoner i Norge griper dette inn i kravene under den nye digitalsikkerhetsloven, der tilgangskontroll og sikker fjerntilgang er uttrykkelige krav.

Komplett eksempelprosjekt: fra null til herdet server

Her er hele flyten samlet, fra en fersk server til en der bare nøkkelinnlogging er tillatt. Kjør dette i rekkefølge fra din lokale maskin. Erstatt sam og IP-adressen med dine egne verdier. Dette er det fullstendige, fungerende prosjektet du kan gjenbruke for hver ny server.

# 1. Generer nokkel (lokalt) hvis du ikke har en
ssh-keygen -t ed25519 -a 100 -C "sam@laptop-2026"

# 2. Last nokkelen inn i agenten
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# 3. Kopier offentlig nokkel til serveren
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# 4. Test nokkelinnlogging
ssh [email protected] "echo 'Nokkelinnlogging fungerer'"

# 5. Lag en config-oppforing (lokalt)
cat >> ~/.ssh/config <<'EOF'
Host produksjon
    HostName 192.0.2.50
    User sam
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
EOF
chmod 600 ~/.ssh/config

Deretter herder du serveren. Logg inn og kjør disse kommandoene på serveren. De skriver de viktigste innstillingene til en egen fil i sshd_config.d, som er den ryddige måten å gjøre det på i moderne Ubuntu.

# Kjores PA serveren, i en apen okt
sudo tee /etc/ssh/sshd_config.d/90-herding.conf > /dev/null <<'EOF'
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no
MaxAuthTries 3
EOF

# Test syntaks og last inn pa nytt
sudo sshd -t && sudo systemctl reload ssh

# IKKE lukk denne okten. Test i et NYTT vindu:
#   ssh produksjon

Når den nye innloggingen i et eget vindu fungerer, er du ferdig. Du har en server der passordbaserte angrep er umulige, der hver innlogging er en kryptografisk signert hendelse, og der hele oppsettet er dokumentert i to korte filer. Gjenta de samme stegene for neste server, og du har en gjentakbar, sikker rutine. Vil du gå videre, kan du sette opp en kryptert tunnel mellom maskinene dine med vår guide til WireGuard VPN på Linux.

Ofte stilte spørsmål om SSH-nøkler

Er en SSH-nøkkel virkelig tryggere enn et sterkt passord?

Ja, med god margin. En Ed25519-nøkkel gir rundt 128 bits sikkerhet, langt mer enn noe passord et menneske kan huske. I tillegg sendes den hemmelige delen aldri til serveren, så den kan ikke fanges underveis eller lekke fra serverens database. Et passord kan phishes, gjettes eller fanges av en keylogger. En privat nøkkel som er beskyttet med passordfrase, har ingen av disse svakhetene.

Hva skjer hvis jeg mister den private nøkkelen?

Da mister du muligheten til å logge inn med den nøkkelen, men ingen andre kan bruke den hvis den var beskyttet med en passordfrase. Du fjerner den offentlige nøkkelen fra authorized_keys på serverne og legger inn en ny nøkkel. Derfor er det lurt å ha en alternativ innloggingsmetode, for eksempel en reservenøkkel, og å sette passordfrase på nøklene.

Kan jeg bruke samme nøkkel på flere maskiner?

Teknisk ja, men det anbefales ikke. Bedre praksis er én nøkkel per enhet. Da kan du tilbakekalle nøkkelen til en stjålet laptop uten å påvirke de andre enhetene dine. Den offentlige delen av hver nøkkel legges i authorized_keys på serverne du vil nå.

Trenger jeg passordfrase hvis nøkkelen ligger på en kryptert disk?

Ja. Diskkryptering beskytter når maskinen er avslått, men når du er logget inn, ligger nøkkelen tilgjengelig. En passordfrase gir et ekstra lag som beskytter selv om noen får tilgang til en påslått, ulåst maskin. Med ssh-agent merker du knapt forskjellen i hverdagen.

Hvilken nøkkeltype bør jeg velge i 2026?

Ed25519 for alle nye nøkler. Den er rask, liten og uten kjente svakheter i bruk. Velg RSA 4096 bare hvis du møter et eldre system som ikke støtter Ed25519. Unngå ECDSA med mindre du må av kompatibilitetshensyn, og bruk aldri DSA, som er fjernet fra OpenSSH 10.

Hvordan fjerner jeg en nøkkel jeg ikke lenger stoler på?

Logg inn på serveren og slett den aktuelle linjen fra ~/.ssh/authorized_keys. Nøkkelen mister da all tilgang umiddelbart. Bruker du SSH-sertifikater, lar du i stedet sertifikatet utløpe eller legger nøkkelen i en tilbakekallingsliste (KRL). For flere servere automatiserer du jobben med et verktøy som Ansible.

Beskytter SSH meg mot kvantedatamaskiner?

Delvis, og det blir stadig bedre. OpenSSH 10 bruker en post-kvante hybrid nøkkelutveksling som standard for selve tunnelen, så trafikken din er beskyttet mot fremtidig kvantedekryptering av lagret data. Selve autentiseringsnøklene (Ed25519, RSA) er foreløpig klassiske, men det viktigste, fortroligheten til trafikken, er allerede kvantesikret. Hold OpenSSH oppdatert for å få med deg utviklingen.

Hvorfor blir jeg fortsatt bedt om passord etter at jeg satte opp nøkkelen?

Da brukes ikke nøkkelen. De vanligste årsakene er feil rettigheter på ~/.ssh eller authorized_keys på serveren, at nøkkelen ligger hos feil bruker, eller at serveren har PubkeyAuthentication no. Kjør ssh -v og se etter «Server accepts key». Mangler den linjen, ligger problemet på serversiden, oftest i rettighetene.