Lösenord är den svagaste länken i nästan varje serverintrång. Angripare kör automatiserade ordlistor mot port 22 dygnet runt, och en exponerad server ser ofta tusentals inloggningsförsök per dygn redan första veckan online. SSH-nycklar löser problemet vid roten: i stället för en hemlighet du kan gissa använder du ett kryptografiskt nyckelpar som är praktiskt taget omöjligt att forcera. Den här guiden tar dig genom 12 konkreta steg, från att skapa din första ed25519-nyckel till en helt härdad sshd_config med fail2ban och moderna, kvantsäkra nyckelutbyten.
Vi använder OpenSSH 10.x, som är standard i Ubuntu, Debian, Fedora och de flesta moderna Linux-distributioner under 2026. Hela arbetsflödet tar ungefär 20 minuter, och du behöver inga betaltjänster. När du är klar loggar du in utan lösenord, har stängt av lösenordsinloggning helt och har ett verktyg som blockerar brute force-angrepp automatiskt.
Varför SSH-nycklar slår lösenord
SSH (Secure Shell) är protokollet som administratörer använder för att fjärrstyra servrar. Som standard tillåter många system inloggning med användarnamn och lösenord, och det är exakt den dörren angripare bankar på. Ett lösenord på tolv tecken kan kännas starkt, men mot en automatiserad attack som testar miljontals kombinationer från ett botnät är marginalen mindre än du tror. En SSH-nyckel bygger i stället på asymmetrisk kryptering: en privat nyckel som aldrig lämnar din dator och en publik nyckel som du lägger på servern.
Skillnaden i praktiken är enorm. En ed25519-nyckel har en effektiv säkerhetsnivå runt 128 bitar, vilket motsvarar att gissa ett slumpmässigt lösenord på cirka 22 tecken. Ingen ordlista i världen kommer åt den. Lägg till att nyckeln aldrig skickas över nätverket, och du eliminerar både gissningsattacker och risken att ett lösenord fångas upp på vägen.
Det handlar inte bara om teori. Brute force mot SSH är en av de vanligaste ingångarna i ransomware-incidenter, och exponerade servrar utan nyckelautentisering hör till de första som komprometteras. Att gå över till nycklar och stänga av lösenord är den enskilt största säkerhetsvinsten du kan göra på en Linux-server, och den kostar ingenting. Samma princip med publika och privata nycklar ligger bakom digitala signaturer och PGP-kryptering med GPG.
Så fungerar SSH-nyckelautentisering
Asymmetrisk kryptering använder två matematiskt sammanlänkade nycklar. Det som krypteras eller signeras med den ena kan bara verifieras med den andra, men du kan inte räkna ut den privata nyckeln från den publika. Det är denna envägsrelation som gör nyckelautentisering säker.
När du ansluter sker en handskakning i fyra steg. Klienten meddelar vilken publik nyckel den vill använda. Servern kontrollerar att samma publika nyckel finns i filen ~/.ssh/authorized_keys för det kontot. Servern skickar en kryptografisk utmaning. Klienten signerar utmaningen med sin privata nyckel och skickar tillbaka beviset. Servern verifierar signaturen mot den publika nyckeln och släpper in dig. Den privata nyckeln lämnar aldrig din maskin, och inget hemligt material går över ledningen.
Den privata nyckeln bör i sin tur skyddas med en lösenfras. Då krävs två saker för att logga in: filen med nyckeln och lösenfrasen som låser upp den. Det är tvåfaktorsprincipen i miniatyr, något du har och något du vet. Lösenfrasen verifieras lokalt på din dator och skickas aldrig till servern, så även en server som blivit komprometterad ser den aldrig.
Förutsättningar och versioner
Innan du börjar behöver du följande. Versionerna nedan är vad som gäller under 2026, men nyare fungerar lika bra.
- En klientdator med Linux, macOS eller Windows 10/11. OpenSSH-klienten är förinstallerad på alla tre.
- En Linux-server du har root- eller sudo-åtkomst till (Ubuntu 24.04 LTS, Debian 12/13, Fedora 41+ eller liknande).
- OpenSSH 9.0 eller senare på både klient och server. OpenSSH 10.x är standard i 2026 års distributioner och rekommenderas.
- Terminalåtkomst och grundläggande vana vid kommandoraden.
- Ett befintligt sätt att logga in (lösenord eller konsol) så att du inte låser ute dig själv medan du konfigurerar.
Ett varningsord innan vi börjar: håll alltid en andra session öppen mot servern medan du ändrar i sshd_config. Om du råkar konfigurera fel och stänger din enda anslutning kan du bli utelåst. Med en extra session kan du alltid ångra ändringen. Många molnleverantörer erbjuder dessutom en webbkonsol som ett sista skyddsnät.
Steg 1: Kontrollera din OpenSSH-version
Kontrollera först vilken version du kör. Vissa funktioner i den här guiden, som det kvantsäkra nyckelutbytet, kräver OpenSSH 9.0 eller senare. Kör på både klient och server:
ssh -VDu får ut något i stil med:
OpenSSH_10.0p1, OpenSSL 3.4.1 1 Apr 2026Är versionen äldre än 9.0 bör du uppdatera. På Debian och Ubuntu räcker oftast sudo apt update && sudo apt upgrade openssh-server openssh-client, på Fedora sudo dnf upgrade openssh openssh-server. OpenSSH 10.0 släpptes i april 2025 och gjorde det kvantsäkra nyckelutbytet mlkem768x25519-sha256 till standard, så ju nyare desto bättre.
Steg 2: Generera ett ed25519-nyckelpar
Nu skapar vi själva nyckelparet. Vi väljer ed25519, som är snabbare, kortare och minst lika säkert som RSA. På din klientdator (inte servern), kör:
ssh-keygen -t ed25519 -a 100 -C "sam@laptop-2026"Flaggorna betyder följande. -t ed25519 väljer nyckeltypen. -a 100 sätter antalet KDF-rundor som skyddar den krypterade privata nyckeln; ett högre tal gör en stulen nyckelfil dyrare att forcera. -C är en kommentar som hjälper dig känna igen nyckeln senare, till exempel vem och vilken dator den tillhör. Du får sedan frågor:
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:9xQ2k...8fT0 sam@laptop-2026Tryck Enter för standardsökvägen om du inte redan har en nyckel med samma namn. Ange en stark lösenfras när den frågas. Du får nu två filer: id_ed25519 (privat, dela aldrig) och id_ed25519.pub (publik, den som ska till servern).
ed25519, RSA eller ECDSA?
Du kan välja andra nyckeltyper, men för nya nycklar 2026 är ed25519 standardvalet. Tabellen visar varför.
| Nyckeltyp | Nyckellängd | Säkerhetsnivå | Rekommendation 2026 |
|---|---|---|---|
| ed25519 | 256 bitar | ~128 bitar | Förstahandsval för nya nycklar |
| ecdsa (nistp256) | 256 bitar | ~128 bitar | Fungerar, men ed25519 föredras |
| rsa 4096 | 4096 bitar | ~140 bitar | Endast för bakåtkompatibilitet |
| rsa 3072 | 3072 bitar | ~128 bitar | Minimum om RSA krävs |
| rsa 2048 | 2048 bitar | ~112 bitar | Undvik, för svag på sikt |
Behöver du RSA av kompatibilitetsskäl, kör ssh-keygen -t rsa -b 4096 -a 100. För allt annat är ed25519 snabbare att verifiera, ger kortare nycklar och har inga av de svagheter i slumptalsgenerering som drabbat ECDSA-implementeringar historiskt.
Steg 3: Skydda den privata nyckeln
Den privata nyckeln är hela ditt försvar. Hamnar den i fel händer utan lösenfras är spelet över. Två saker gäller: rätt filrättigheter och en stark lösenfras.
OpenSSH vägrar använda en privat nyckel som är läsbar för andra användare. Säkerställ rätt rättigheter:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pubHoppade du över lösenfrasen i steg 2 kan du lägga till en i efterhand utan att skapa en ny nyckel:
ssh-keygen -p -a 100 -f ~/.ssh/id_ed25519En lösenfras gör att en stulen nyckelfil är värdelös utan den. Välj en lång fras med flera ord, gärna hanterad i din lösenordshanterare. Vi visar i steg 11 hur ssh-agent gör att du bara behöver skriva lösenfrasen en gång per session, så bekvämligheten kostar dig nästan ingenting.
Steg 4: Kopiera den publika nyckeln till servern
Nu lägger vi den publika nyckeln på servern. Det enklaste sättet är ssh-copy-id, som hanterar både rättigheter och kataloger åt dig:
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]Byt ut sam mot ditt användarnamn och 192.0.2.10 mot serverns IP-adress eller värdnamn. Du loggar in med lösenord en sista gång, och kommandot lägger nyckeln i ~/.ssh/authorized_keys. Utdata ser ut så här:
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.Saknar systemet ssh-copy-id, exempelvis på vissa minimala installationer eller Windows, kan du göra det manuellt:
cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
"mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"Båda metoderna ger samma resultat: din publika nyckel finns nu i serverns lista över betrodda nycklar för ditt konto.
Steg 5: Logga in och verifiera nyckelautentisering
Testa nu att nyckeln fungerar innan vi rör servern vidare. Logga in:
ssh [email protected]Om du satte en lösenfras blir du ombedd att låsa upp den lokala nyckeln, inte att ange ett serverlösenord. För att se exakt vad som händer, kör med utförlig loggning:
ssh -v [email protected] 2>&1 | grep -i "authentication\|offering\|accepted"Den rad du vill se bekräftar publik nyckel-autentisering:
debug1: Offering public key: /home/sam/.ssh/id_ed25519 ED25519 SHA256:9xQ2k...8fT0
debug1: Server accepts key: /home/sam/.ssh/id_ed25519 ED25519 SHA256:9xQ2k...8fT0
debug1: Authentication succeeded (publickey).Ser du Authentication succeeded (publickey) är nyckeln på plats. Det här steget är kritiskt: bekräfta att nyckelinloggningen fungerar innan du stänger av lösenord i nästa steg, annars riskerar du att låsa ute dig själv.
Steg 6: Konfigurera klienten med ~/.ssh/config
Att skriva fullständig adress och flaggor varje gång blir snabbt tröttsamt. En klientkonfiguration på din egen dator gör inloggningen kortare och tydligare. Skapa eller redigera ~/.ssh/config:
Host webbserver
HostName 192.0.2.10
User sam
Port 22
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
AddKeysToAgent yes
Host *
ServerAliveInterval 60
ServerAliveCountMax 3Nu räcker det att skriva ssh webbserver. IdentitiesOnly yes ser till att bara den angivna nyckeln erbjuds, vilket undviker problem om du har många nycklar. ServerAliveInterval håller anslutningen vid liv genom brandväggar som annars stänger inaktiva sessioner. Sätt rätt rättigheter på filen:
chmod 600 ~/.ssh/configSteg 7: Härda sshd_config på servern
Nu kommer den viktigaste delen: att stänga av lösenordsinloggning på servern. Öppna serverns konfiguration med en andra session redan igång (se varningen i förutsättningarna):
sudo nano /etc/ssh/sshd_configSätt eller ändra följande rader. På moderna system ligger en del inställningar i /etc/ssh/sshd_config.d/, så kontrollera att ingen fil där skriver över dina värden.
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
PermitEmptyPasswords no
UsePAM yesPasswordAuthentication no är raden som stänger dörren för brute force. KbdInteractiveAuthentication no och ChallengeResponseAuthentication no stänger alternativa lösenordsprompter så att de inte kan kringgå din avsikt. PermitRootLogin prohibit-password tillåter root endast via nyckel, aldrig med lösenord. Testa konfigurationen innan du laddar om:
sudo sshd -t && sudo systemctl reload sshsshd -t kontrollerar syntaxen och vägrar ladda om vid fel, vilket skyddar dig från att låsa ute dig. På vissa distributioner heter tjänsten sshd i stället för ssh; använd då sudo systemctl reload sshd. Öppna nu en helt ny terminal och testa att logga in. Lyckas det, och ett försök med lösenord nekas, är härdningen klar.
Steg 8: Moderna krypton och kvantsäkert nyckelutbyte
OpenSSH 10.x väljer redan starka algoritmer som standard, men du kan begränsa servern till enbart moderna val. Det skyddar mot nedgraderingsattacker och förbereder för kvantdatorer. Lägg till i sshd_config:
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha256,curve25519-sha256
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512Nyckelutbytet mlkem768x25519-sha256 är ett hybridutbyte: det kombinerar den klassiska Curve25519 med ML-KEM (tidigare Kyber), en algoritm som NIST standardiserat som kvantsäker. Hybriden betyder att anslutningen förblir säker även om den ena delen knäcks. OpenSSH införde det äldre sntrup761x25519-sha256 som standard redan i version 9.0 (2022) och gjorde mlkem768x25519-sha256 till standard i version 10.0 (2025).
Varför bry sig om kvantsäkerhet redan nu? Angripare samlar krypterad trafik idag i hopp om att kunna dekryptera den senare med en kvantdator, en strategi som kallas “skörda nu, dekryptera sedan”. Hybridutbytet stänger den dörren. Vi går djupare i ämnet i vår guide om HTTPS och TLS. Tabellen sammanfattar OpenSSH:s väg mot kvantsäkerhet.
| OpenSSH-version | Släppt | Milstolpe för nyckelutbyte |
|---|---|---|
| 9.0 | April 2022 | sntrup761x25519-sha256 som standard |
| 9.9 | September 2024 | mlkem768x25519-sha256 infört |
| 10.0 | April 2025 | mlkem768x25519-sha256 blir standard |
| 10.x | 2026 | Fortsatt härdning av standardvärden |
Glöm inte att köra sudo sshd -t och ladda om efter ändringen. Sätter du för restriktiva algoritmer kan äldre klienter tappa anslutningen, så testa från alla maskiner du behöver komma åt.
Steg 9: Begränsa åtkomst och försök
Med lösenord avstängt är det redan svårt att ta sig in, men vi kan minska attackytan ytterligare. Lägg till i sshd_config:
AllowUsers sam deploy
MaxAuthTries 3
LoginGraceTime 20
MaxSessions 4
MaxStartups 10:30:60
X11Forwarding no
AllowAgentForwarding noAllowUsers är en vitlista: bara de namngivna kontona får logga in, alla andra nekas direkt. MaxAuthTries 3 bryter anslutningen efter tre misslyckade försök. LoginGraceTime 20 ger bara tjugo sekunder att autentisera, vilket också mildrar sårbarheter som regreSSHion (mer om den i avsnittet om kända hot). X11Forwarding no stänger en funktion de flesta servrar inte behöver. Som alltid: testa med sshd -t och ladda om.
Vill du flytta SSH till en annan port än 22 kan du sätta Port 2222. Det stoppar inte en riktad angripare, men minskar bruset från automatiska skannrar avsevärt. Kom ihåg att öppna porten i brandväggen och uppdatera din klientkonfiguration.
Steg 10: Installera och konfigurera fail2ban
fail2ban läser serverns loggar och blockerar IP-adresser som gör för många misslyckade försök. Det är ett reaktivt skydd, men en bra extra mur ovanpå nyckelautentiseringen. Installera:
sudo apt update && sudo apt install fail2ban -ySkapa en lokal konfiguration så att en paketuppdatering inte skriver över dina inställningar. Redigera /etc/fail2ban/jail.local:
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 3
backend = systemd
[sshd]
enabled = true
port = ssh
maxretry = 3Det betyder: tre misslyckade försök inom tio minuter ger en timmes bannlysning. Många väljer en längre bantime, exempelvis 24h, för att hålla envisa angripare borta längre. Starta tjänsten och kontrollera status:
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdUtdata visar hur många IP-adresser som blockerats:
Status for the jail: sshd
|- Filter
| |- Currently failed: 2
| |- Total failed: 148
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 5
|- Total banned: 37
`- Banned IP list: 203.0.113.44 198.51.100.7 ...Siffrorna under “Total failed” och “Total banned” ger en känsla för hur mycket automatisk trafik en exponerad server faktiskt utsätts för. För nätverkshärdning i stort, se vår guide om WireGuard VPN på egen server, ett ännu starkare sätt att gömma SSH bakom en VPN.
Steg 11: Använd ssh-agent för bekväm nyckelhantering
En lösenfras är säker men kan kännas omständlig om du loggar in ofta. ssh-agent löser det genom att hålla din upplåsta nyckel i minnet under sessionen, så du bara skriver lösenfrasen en gång. Starta agenten och lägg till nyckeln:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519På de flesta skrivbordsmiljöer startar agenten automatiskt. Med AddKeysToAgent yes i klientkonfigurationen (steg 6) läggs nyckeln till första gången du använder den. Lista laddade nycklar med ssh-add -l och ta bort alla med ssh-add -D när du är klar för dagen.
En varning om agentvidarebefordran (ForwardAgent): den låter en fjärrserver använda din lokala nyckel, men en komprometterad server kan då missbruka den. Använd hellre ProxyJump (se avancerade tips) som är säkrare. Vi satte därför AllowAgentForwarding no på servern i steg 9.
Steg 12: Sluttest och säker återställning
Sista steget är att verifiera helheten och veta hur du tar dig tillbaka om något går fel. Kör en fullständig kontroll från en ny terminal:
- Logga in med nyckel:
ssh webbserverska fungera utan serverlösenord. - Bekräfta att lösenord nekas:
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no [email protected]ska avvisas. - Kontrollera fail2ban:
sudo fail2ban-client status sshdska visa jail som aktiv. - Verifiera algoritmer:
ssh -v webbserver 2>&1 | grep "kex:"ska visa mlkem768x25519-sha256.
Skulle du av misstag låsa ute dig själv: använd molnleverantörens webbkonsol eller fysisk konsolåtkomst, redigera /etc/ssh/sshd_config tillbaka till PasswordAuthentication yes, kör sudo systemctl reload ssh och börja om. Det är just därför du alltid ska ha en andra session öppen under konfigurationen. Med allt grönt har du en server som motstår praktiskt taget alla automatiska SSH-attacker.
Komplett, härdad sshd_config
Här är hela projektet samlat: en färdig serverkonfiguration som kombinerar alla steg. Anpassa AllowUsers och eventuell Port efter din miljö, kör sudo sshd -t och ladda om.
# /etc/ssh/sshd_config - härdad för 2026
# Autentisering
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
PermitEmptyPasswords no
UsePAM yes
# Åtkomst och gränser
AllowUsers sam deploy
MaxAuthTries 3
LoginGraceTime 20
MaxSessions 4
MaxStartups 10:30:60
# Moderna, kvantsäkra algoritmer
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha256,curve25519-sha256
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512
# Stäng av onödiga funktioner
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PrintMotd no
# Loggning för fail2ban och granskning
LogLevel VERBOSELogLevel VERBOSE loggar fingeravtrycket på den nyckel som använts vid varje inloggning, vilket är guld vid en granskning. Med den här filen och fail2ban på plats har du en konfiguration som ligger steget före de allra flesta servrar på nätet.
Öppna rätt port i brandväggen med ufw
En härdad SSH-tjänst hjälper föga om brandväggen lämnar allt annat öppet. På Ubuntu och Debian är ufw (Uncomplicated Firewall) det enklaste verktyget. Tanken är att neka all inkommande trafik som standard och bara släppa in det du faktiskt behöver, vilket krymper attackytan dramatiskt.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verboseProfilen OpenSSH öppnar port 22. Flyttade du SSH till en egen port i steg 9 anger du i stället portnumret direkt, exempelvis sudo ufw allow 2222/tcp. Statuskontrollen visar de aktiva reglerna:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
To Action From
-- ------ ----
22/tcp (OpenSSH) ALLOW IN Anywhere
22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)Vill du begränsa SSH till ett enda kontorsnät kan du låsa regeln till en IP eller ett subnät: sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp. En sådan källbegränsning är ett av de mest effektiva enskilda skydden, eftersom skannrar från resten av internet då aldrig ens når tjänsten. Kombinera det gärna med att gömma SSH bakom en WireGuard-VPN, så att port 22 inte är exponerad mot internet alls.
Glöm inte att verifiera att du fortfarande kommer in efter ufw enable. Precis som med sshd_config gäller principen att hålla en andra session öppen tills du bekräftat att den nya regeluppsättningen släpper in dig. En felaktig brandväggsregel kan låsa ute dig lika effektivt som en felaktig SSH-konfiguration.
Säkerhetskopiera och rotera dina nycklar
Förlorar du din privata nyckel utan en kopia förlorar du åtkomsten till varje server där den ligger. Säkerhetskopiera därför nyckelparet på ett säkert sätt, inte i en oskyddad molnmapp. Ett krypterat USB-minne eller en post i din lösenordshanterare fungerar bra. Tänk på att en kopia av en privat nyckel är lika känslig som originalet och ska skyddas lika hårt.
Rotera nycklar med jämna mellanrum, exempelvis en gång om året, eller omedelbart vid minsta misstanke om att en dator komprometterats. Rotationen är okomplicerad: generera ett nytt par, lägg till den nya publika nyckeln på servrarna, verifiera att inloggning fungerar, och ta sedan bort den gamla raden ur authorized_keys.
# 1. Generera ny nyckel
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_ny -C "sam@laptop-2026-ny"
# 2. Distribuera den nya publika nyckeln
ssh-copy-id -i ~/.ssh/id_ed25519_ny.pub [email protected]
# 3. Verifiera att den nya nyckeln fungerar
ssh -i ~/.ssh/id_ed25519_ny [email protected]
# 4. Ta bort den gamla nyckelns rad ur authorized_keys på servernVill du granska vilka nycklar som faktiskt ligger på en server kan du läsa authorized_keys direkt: cat ~/.ssh/authorized_keys. Jämför fingeravtrycken med dina egna nycklar via ssh-keygen -lf ~/.ssh/id_ed25519.pub. Hittar du en rad du inte känner igen ska du behandla det som ett möjligt intrång, ta bort raden direkt och granska serverns loggar.
SSH-nycklar på Windows
Windows 10 och 11 har en inbyggd OpenSSH-klient, så kommandona i den här guiden fungerar direkt i PowerShell eller Terminal. Nycklar hamnar i C:\Users\<namn>\.ssh\. Använder du PuTTY i stället hanteras nycklar i PuTTYgen-format (.ppk), och du kan importera en befintlig ed25519-nyckel via menyn Conversions. För de flesta räcker den inbyggda klienten, som beter sig exakt som på Linux och macOS, inklusive ssh-copy-id i nyare versioner.
Vanliga fallgropar att undvika
Även enkla SSH-uppsättningar går ofta fel på samma punkter. Här är de vanligaste misstagen och hur du undviker dem.
- Stänger av lösenord innan nyckeln testats. Bekräfta alltid att
Authentication succeeded (publickey)dyker upp (steg 5) innan du sätterPasswordAuthentication no. Annars riskerar du att låsa ute dig. - Fel filrättigheter. OpenSSH ignorerar tyst en
authorized_keyseller privat nyckel som är för öppen. Kontrollera 700 på~/.ssh, 600 på privata nycklar och 600 påauthorized_keys. - En fil i sshd_config.d skriver över dina värden. På Ubuntu och Debian inkluderas
/etc/ssh/sshd_config.d/*.conf, och en molnleverantörs fil där kan återaktivera lösenord. Kontrollera medsudo sshd -T | grep -i passwordauthentication. - Glömmer ladda om tjänsten. Ändringar i
sshd_configgäller först eftersystemctl reload ssh. Befintliga sessioner påverkas inte, vilket är bra, men nya följer den nya konfigurationen. - Privat nyckel utan lösenfras på en bärbar dator. Tappar du datorn ligger nyckeln öppen. Sätt alltid en lösenfras och använd ssh-agent för bekvämligheten.
- Samma nyckel på alla maskiner. Använd separata nycklar per dator. Blir en stulen behöver du bara återkalla den ena ur
authorized_keys, inte byta överallt.
Felsökning: åtta vanliga problem
När inloggningen inte fungerar är ssh -v din bästa vän. Tabellen listar de vanligaste felmeddelandena och deras lösning.
| Symptom | Trolig orsak | Lösning |
|---|---|---|
| Permission denied (publickey) | Nyckeln saknas eller fel rättigheter på authorized_keys | Kontrollera 600 på authorized_keys, 700 på ~/.ssh, rätt ägare |
| Frågar fortfarande efter lösenord | Servern hittar inte nyckeln eller fel användarnamn | Kör ssh -v och kontrollera att rätt IdentityFile erbjuds |
| Too many authentication failures | ssh-agent erbjuder för många nycklar | Lägg till IdentitiesOnly yes i ~/.ssh/config |
| Connection refused | sshd kör inte eller fel port | Kontrollera systemctl status ssh och brandväggens portregel |
| Connection timed out | Brandvägg eller säkerhetsgrupp blockerar porten | Öppna porten i molnets säkerhetsgrupp och i ufw |
| Host key verification failed | Serverns värdnyckel har ändrats | Verifiera att det är rätt server, ta bort gammal rad med ssh-keygen -R |
| no matching key exchange method | För restriktiva KexAlgorithms mot äldre klient | Lägg till curve25519-sha256 eller uppdatera klienten |
| Agent admitted failure to sign | Nyckeln är inte laddad i agenten | Kör ssh-add ~/.ssh/id_ed25519 och kontrollera med ssh-add -l |
Ett sista tips: serverns loggar avslöjar ofta orsaken direkt. Kör sudo journalctl -u ssh -f på servern medan du försöker logga in, så ser du exakt varför ett försök avvisas. Vid problem med fel filrättigheter loggar sshd typiskt “Authentication refused: bad ownership or modes”.
Kända SSH-hot du bör känna till
SSH är robust, men implementeringar har haft allvarliga sårbarheter de senaste åren. Att känna till dem hjälper dig förstå varför uppdateringar och korta tidsgränser spelar roll.
regreSSHion (CVE-2024-6387) avslöjades av Qualys i juli 2024 och är en sällsynt allvarlig sak: ett kapplöpningsfel i sshd:s signalhanterare som kan ge oautentiserad fjärrkörning av kod som root på glibc-baserade Linux-system. Den fick CVSS-poängen 8.1 och drabbade en rad OpenSSH-versioner i 8.5p1-serien och framåt på sårbara byggen. Försvaret är att hålla OpenSSH uppdaterat och att korta LoginGraceTime, eftersom buggen utnyttjar tidsfönstret innan autentisering.
Terrapin (CVE-2023-48795) är en attack mot själva SSH-transportlagret. Genom att manipulera sekvensnummer i handskakningen kan en angripare i mitten klippa bort meddelanden och tysta nedgradera säkerheten i vissa algoritmkombinationer. Det är inte en lösenords- eller nyckelläcka, utan en integritetsbrist. Den åtgärdas genom uppdaterad OpenSSH på båda sidor och genom att föredra moderna AEAD-krypton som vi satte i steg 8.
| Sårbarhet | CVE | Typ | Försvar |
|---|---|---|---|
| regreSSHion | CVE-2024-6387 | Oautentiserad RCE som root (CVSS 8.1) | Uppdatera OpenSSH, korta LoginGraceTime |
| Terrapin | CVE-2023-48795 | Nedgradering av transportintegritet | Uppdatera båda sidor, moderna AEAD-krypton |
Lärdomen är enkel: nyckelautentisering skyddar mot gissning, men bara uppdaterad mjukvara skyddar mot sårbarheter i själva koden. Håll openssh-server uppdaterat, gärna med automatiska säkerhetsuppdateringar via unattended-upgrades på Debian och Ubuntu.
Avancerade tips för proffs
Hårdvarunycklar med FIDO2
För den högsta säkerhetsnivån kan du binda nyckeln till en fysisk säkerhetsnyckel som en YubiKey. Den privata nyckeln lämnar då aldrig hårdvaran, och du måste röra vid enheten för varje inloggning:
ssh-keygen -t ed25519-sk -O resident -O verify-requiredSuffixet -sk står för security key. verify-required kräver dessutom en PIN-kod. Även om någon stjäl både datorn och nyckelfilen kan de inte logga in utan den fysiska enheten.
Hoppa via bastionvärd med ProxyJump
I miljöer där interna servrar bara nås via en bastionvärd slipper du dubbla inloggningar med ProxyJump i klientkonfigurationen:
Host intern-db
HostName 10.0.1.20
User sam
ProxyJump bastion.example.com
IdentityFile ~/.ssh/id_ed25519Då tunnlar SSH automatiskt genom bastionvärden utan att din privata nyckel någonsin landar på den, vilket är säkrare än agentvidarebefordran.
SSH-certifikat i större miljöer
När du hanterar dussintals servrar blir authorized_keys ohållbart. SSH-certifikat låter dig signera användarnycklar med en betrodd CA och sätta utgångstid, så du slipper kopiera nycklar manuellt. Det bygger på samma matematik som digitala signaturer och är hur stora organisationer skalar SSH säkert.
Vanliga frågor om SSH-nycklar
Är SSH-nycklar säkrare än lösenord?
Ja, betydligt. En ed25519-nyckel har en säkerhetsnivå runt 128 bitar, motsvarande ett slumpmässigt lösenord på drygt 20 tecken, och den skickas aldrig över nätverket. Lösenord kan gissas med ordlistor och fångas upp; nycklar kan inte forceras med rimliga resurser. När du dessutom stänger av lösenordsinloggning eliminerar du brute force helt.
Behöver jag en lösenfras på min SSH-nyckel?
Ja, på alla nycklar som lagras på en dator du bär med dig eller som kan stjälas. Lösenfrasen krypterar den privata nyckelfilen så att en stulen fil är värdelös. Med ssh-agent skriver du lösenfrasen bara en gång per session, så det blir inte omständligt. För automatiserade tjänstekonton används ibland nycklar utan lösenfras, men då bör de begränsas hårt med command= och IP-restriktioner i authorized_keys.
ed25519 eller RSA, vilken ska jag välja 2026?
Välj ed25519 för alla nya nycklar. Den är snabbare, ger kortare nycklar och har inga av de implementeringssvagheter som drabbat ECDSA. RSA behövs bara om du måste prata med mycket gammal utrustning, och då ska du använda minst 3072 bitar, helst 4096.
Vad är kvantsäkert nyckelutbyte i SSH?
Det är ett hybridutbyte, mlkem768x25519-sha256, som kombinerar klassisk Curve25519 med den NIST-standardiserade kvantsäkra algoritmen ML-KEM. Det skyddar mot framtida kvantdatorer och mot “skörda nu, dekryptera sedan”-attacker. OpenSSH 10.0 gjorde det till standard 2025, så du får skyddet automatiskt på moderna system.
Hur tar jag bort åtkomst för en gammal nyckel?
Ta bort motsvarande rad ur ~/.ssh/authorized_keys på servern. Nyckeln slutar fungera omedelbart för nya anslutningar. Därför är det klokt att ha separata nycklar per dator: blir en stulen återkallar du bara den raden utan att påverka dina andra maskiner.
Kan jag använda samma SSH-nyckel på flera servrar?
Tekniskt ja, du lägger samma publika nyckel i authorized_keys på varje server. Det är vanligt och säkert så länge den privata nyckeln skyddas väl. Däremot bör du ha olika nycklar per klientdator, inte per server, så att en komprometterad laptop bara påverkar sina egna anslutningar.
Varför nekas jag fortfarande efter att jag lagt till nyckeln?
Nästan alltid handlar det om filrättigheter eller ägarskap. OpenSSH ignorerar tyst en authorized_keys som är skrivbar för andra. Kontrollera 700 på ~/.ssh och 600 på authorized_keys, att rätt användare äger filerna, och kör ssh -v för att se exakt var det stoppar. Serverns logg via journalctl -u ssh avslöjar ofta orsaken på en rad.
Räcker fail2ban som skydd?
Nej, fail2ban är ett reaktivt komplement, inte ett primärt försvar. Den blockerar IP-adresser efter misslyckade försök, men det effektiva skyddet är att stänga av lösenord helt så att det inte finns något att gissa. Använd fail2ban ovanpå nyckelautentisering, inte i stället för den.
Relaterad läsning
- WireGuard VPN: egen server i 12 steg, 30 min [2026]
- PGP-kryptering med GPG: e-post i 12 steg [2026]
- VeraCrypt: kryptera en disk i 12 steg [2026]
- Lösenordssäkerhet: längd, hashning och lösenordshanterare
- Digitala signaturer: hashfunktioner och asymmetriska nycklar
- HTTPS och TLS: hänglåset, certifikat och vad de skyddar
- Cybersäkerhet: nav för guider och analyser
Externa källor: OpenSSH Release Notes, OpenSSH 10.0, Qualys regreSSHion-rådgivning (CVE-2024-6387), Terrapin Attack (CVE-2023-48795) och OpenBSD sshd_config-manual.
