SSH-säkerhet och autentisering 20 min läsning

SSH-härdning 2026: Postkvant-kryptografi, FIDO2-nycklar och certifikat i OpenSSH

Guide till modern SSH-härdning: OpenSSH 10.0 med postkvant-kryptografi (ML-KEM), FIDO2-hårdvarunycklar, certifikatbaserad autentisering via SSH CA, och en komplett härdad sshd_config för 2026.

Editorial Team

Varför SSH-säkerhet kräver ett omtag 2026

SSH är ryggraden i Linux-administration — det vet vi alla. Varje sysadmin, DevOps-ingenjör och säkerhetsteam förlitar sig på det dagligen för fjärråtkomst, filöverföring och automatiserade pipelines. Men just det faktum att SSH finns överallt gör det också till en av de mest lockande attackytorna för hotaktörer.

Under 2026 har hotlandskapet förändrats rejält. Din SSH-konfiguration måste hänga med.

Tre stora trender driver behovet av att modernisera SSH-säkerheten:

  • Kvantdatorhotet: "Harvest now, decrypt later"-attacker innebär att angripare redan idag samlar in krypterad SSH-trafik för att dekryptera den när kvantdatorer blir tillräckligt kraftfulla. Det handlar inte om om det händer, utan när.
  • Stulna SSH-nycklar: Traditionella privata SSH-nycklar lagras som filer på disk. Det gör dem sårbara för exfiltrering via malware, komprometterade utvecklarmaskiner och insider-hot.
  • Nyckelspridning: I stora organisationer sprids auktoriserade nycklar okontrollerat över hundratals servrar, utan central hantering eller automatisk utgångstid. Ärligt talat — det är en mardröm för revisioner och compliance.

Den goda nyheten? OpenSSH 10.0, släppt i april 2025, introducerar flera banbrytande säkerhetsförbättringar som adresserar alla dessa utmaningar. I den här guiden går vi igenom hur du implementerar modern SSH-säkerhet på dina Linux-system — från postkvant-kryptografi och FIDO2-hårdvarunycklar till certifikatbaserad autentisering och avancerad härdning av sshd-konfigurationen.

OpenSSH 10.0: De viktigaste säkerhetsförbättringarna

Innan vi dyker in i de praktiska konfigurationerna behöver vi förstå vad OpenSSH 10.0 faktiskt förändrar. Den här versionen är inte bara en vanlig uppdatering — det är ett stort arkitektoniskt och kryptografiskt skifte.

Postkvant-nyckelutbyte som standard

Den mest betydelsefulla förändringen är att mlkem768x25519-sha256 nu är standardalgoritm för nyckelutbyte. ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) är en NIST-standardiserad postkvant-algoritm designad för att motstå attacker från kvantdatorer. Det hybridbaserade tillvägagångssättet kombinerar ML-KEM med den klassiska Curve25519-algoritmen, så säkerheten blir aldrig sämre än vad den klassiska algoritmen erbjuder.

I praktiken betyder det att din SSH-session redan är kvantresistent — utan att du behöver lyfta ett finger, så länge du kör OpenSSH 10.0 eller nyare på båda sidor.

DSA-stödet är borta

OpenSSH 10.0 tar äntligen bort det sedan länge föråldrade DSA-stödet helt. DSA-nycklar har betraktats som osäkra i många år, och nu finns det verkligen ingen ursäkt kvar. Har du fortfarande DSA-nycklar i dina authorized_keys-filer? Då är det hög tid att migrera.

Separerad autentiseringsbinär

En subtil men viktig arkitekturförändring: autentiseringskoden har separerats till en ny binär kallad sshd-auth. Det minskar pre-autentiseringens attackyta avsevärt. Om en sårbarhet finns i autentiseringskoden kan den inte längre direkt kompromissa den fullständiga SSH-daemonen. Smart drag, helt enkelt.

Striktare Diffie-Hellman-inställningar

Finite-field Diffie-Hellman (diffie-hellman-group*) är inaktiverat på serversidan som standard. Det tvingar anslutningar att använda modernare nyckelutbytesalgoritmer, inklusive de postkvant-säkra alternativen.

Kontrollera din nuvarande SSH-säkerhet

Innan du börjar härda SSH-konfigurationen bör du inventera din nuvarande status. Två verktyg är oumbärliga här: ssh-audit och Lynis.

Använda ssh-audit

ssh-audit analyserar din SSH-server eller klient och identifierar svaga algoritmer, sårbara versioner och konfigurationsproblem. Så här kommer du igång:

# Installera ssh-audit
sudo apt install ssh-audit    # Debian/Ubuntu
sudo dnf install ssh-audit    # Fedora/RHEL

# Audita en SSH-server
ssh-audit localhost

# Audita en fjärrserver
ssh-audit din-server.example.com

# Audita med specifik policy (t.ex. OpenSSH 10.0)
ssh-audit --policy openssh_10.0 localhost

ssh-audit ger en detaljerad rapport med färgkodade resultat: grönt för säkra algoritmer, gult för acceptabla men inte idealiska, och rött för algoritmer som bör inaktiveras omedelbart. Verktyget kontrollerar nyckelutbytesalgoritmer, värdnycklar, kryptering och MAC-algoritmer — allt på en gång.

Använda Lynis för SSH-granskning

Lynis utför en bredare systemsäkerhetsgranskning som också täcker SSH:

# Installera Lynis
sudo apt install lynis

# Kör en fullständig granskning
sudo lynis audit system

# Kör enbart SSH-relaterade tester
sudo lynis audit system --tests-from-group ssh

Lynis ger praktiska förslag med konkreta åtgärder. Notera de förslag som relaterar till SSH-härdning — de fungerar som en utmärkt checklista att arbeta igenom.

Postkvant-kryptografi: Konfiguration i praktiken

Även om OpenSSH 10.0 aktiverar postkvant-nyckelutbyte som standard är det viktigt att förstå konfigurationen och verkligen säkerställa att din infrastruktur använder den. Jag har sett alltför många miljöer där folk antar att det "bara fungerar" utan att verifiera.

Verifiera postkvant-nyckelutbyte

Kontrollera vilken nyckelutbytesalgoritm som faktiskt används vid en SSH-anslutning:

# Anslut med verbose-läge för att se nyckelutbyte
ssh -vv user@server 2>&1 | grep "kex:"

# Du bör se något i stil med:
# kex: algorithm: mlkem768x25519-sha256

Om du istället ser curve25519-sha256 eller diffie-hellman-group16-sha512 har du inte postkvant-skydd aktivt. Det beror sannolikt på att klienten eller servern kör en äldre OpenSSH-version.

Konfigurera server för postkvant-kryptografi

Uppdatera din /etc/ssh/sshd_config för att prioritera postkvant-algoritmer:

# /etc/ssh/sshd_config - Postkvant-kryptografisk konfiguration

# Prioritera postkvant-nyckelutbyte
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,[email protected]

# Moderna värdnyckelalgoritmer (inga DSA, inga ECDSA med svaga kurvor)
HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,[email protected],[email protected],[email protected],rsa-sha2-512,rsa-sha2-256

# Starka krypteringsalgoritmer
Ciphers [email protected],[email protected],[email protected]

# Säkra MAC-algoritmer (används bara med icke-AEAD-chiffer)
MACs [email protected],[email protected]

Konfigurera klienten

Uppdatera din klientkonfiguration i ~/.ssh/config så att den matchar:

# ~/.ssh/config - Postkvant-kryptografisk klientkonfiguration

Host *
    # Prioritera postkvant-nyckelutbyte
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

    # Föredra Ed25519 och FIDO2-nycklar
    HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

    # Starka chiffer
    Ciphers [email protected],[email protected],[email protected]

    # Säkra MAC:ar
    MACs [email protected],[email protected]

Hantera bakåtkompatibilitet

I heterogena miljöer där inte alla system kör OpenSSH 10.0 måste du ha en fallback-strategi. Genom att inkludera curve25519-sha256 i din KexAlgorithms-lista kan klienter som inte stöder postkvant-algoritmer fortfarande ansluta — men var medveten om att de anslutningarna inte har kvantresistens.

Du kan logga och övervaka vilka anslutningar som faller tillbaka till klassisk kryptografi:

# Identifiera servrar som inte stöder postkvant-kex
for server in $(cat server_lista.txt); do
    echo "=== $server ==="
    ssh -o BatchMode=yes -o KexAlgorithms=mlkem768x25519-sha256 \
        -o ConnectTimeout=5 "$server" exit 2>&1 | grep -i "kex"
done

FIDO2-hårdvarunycklar för SSH

FIDO2-säkerhetsnycklar — som YubiKey 5, SoloKeys och Google Titan — erbjuder det starkaste skyddet för SSH-autentisering. Den privata nyckeln lämnar aldrig den fysiska hårdvaruenheten, vilket gör det i princip omöjligt att exfiltrera nyckeln via malware eller komprometterade system.

Personligen tycker jag att FIDO2-nycklar är den enskilt viktigaste säkerhetsförbättringen man kan göra för sitt SSH-setup. Kostnaden är låg, och effekten är enorm.

Varför FIDO2 istället för vanliga SSH-nycklar?

Traditionella SSH-nycklar lagras som filer i ~/.ssh/. Även med filsystembehörigheter och lösenordsskydd är de sårbara för:

  • Keylogging och malware: En angripare som komprometterar din arbetsstation kan kopiera nyckelfilen och sniffa lösenordsfrasen.
  • Obehörig användning: Stulna nycklar kan användas utan ägarens vetskap — ingen fysisk bekräftelse krävs.
  • Svåra att revokera: En komprometterad nyckel som finns i authorized_keys på 50 servrar kräver manuell rensning överallt.

FIDO2 löser alla dessa problem på ett elegant sätt:

  • Den privata nyckeln genereras i, och lämnar aldrig, hårdvarunyckeln.
  • Varje signering kräver fysisk beröring av nyckeln (user presence).
  • PIN-kod kan krävas för extra skydd (user verification).
  • Resident keys kan lagras på enheten, vilket möjliggör portabilitet mellan datorer.

Generera FIDO2-baserade SSH-nycklar

OpenSSH stöder FIDO2 via nyckeltypen ed25519-sk (sk = security key):

# Generera en FIDO2-nyckel (kräver en fysisk säkerhetsnyckel)
ssh-keygen -t ed25519-sk -O resident -O verify-required \
    -C "$(whoami)@$(hostname)-$(date +%Y%m%d)"

# Parametrar förklarade:
# -t ed25519-sk     : Använd Ed25519 med FIDO2-stöd
# -O resident       : Lagra nyckeln på enheten (discoverable credential)
# -O verify-required: Kräv PIN-kod vid varje användning
# -C "..."          : Kommentar för identifiering

Du kommer att bli ombedd att trycka på din säkerhetsnyckel under genereringen. Utdata blir två filer:

  • ~/.ssh/id_ed25519_sk — en nyckelreferens (inte den faktiska privata nyckeln, värt att notera)
  • ~/.ssh/id_ed25519_sk.pub — den publika nyckeln att distribuera

Använda resident keys för portabilitet

Med resident keys (discoverable credentials) lagras nyckeln direkt på FIDO2-enheten. Det innebär att du kan använda samma säkerhetsnyckel på flera datorer utan att kopiera filer — riktigt smidigt om du jobbar från flera maskiner:

# Importera nycklar från FIDO2-enheten till en ny dator
ssh-keygen -K

# Detta laddar ner nyckelreferenserna till aktuell katalog.
# Flytta dem sedan till rätt plats:
mv id_ed25519_sk_rk ~/.ssh/id_ed25519_sk
mv id_ed25519_sk_rk.pub ~/.ssh/id_ed25519_sk.pub
chmod 600 ~/.ssh/id_ed25519_sk
chmod 644 ~/.ssh/id_ed25519_sk.pub

Konfigurera servern för att acceptera FIDO2-nycklar

På serversidan behöver du lägga till den publika FIDO2-nyckeln i authorized_keys och konfigurera sshd:

# /etc/ssh/sshd_config - FIDO2-konfiguration

# Inkludera FIDO2-nyckeltyper
PubkeyAcceptedAlgorithms [email protected],[email protected],ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

# Aktivera pubkey-autentisering
PubkeyAuthentication yes

# Inaktivera lösenordsautentisering helt
PasswordAuthentication no
KbdInteractiveAuthentication no

Tvinga FIDO2 med verify-required

Du kan kräva att användaren verifierar sin identitet (PIN + fysisk beröring) vid varje inloggning genom att lägga till verify-required-flaggan i authorized_keys:

# ~/.ssh/authorized_keys
verify-required [email protected] AAAAGnN... user@host-20260209

Med den här konfigurationen måste användaren både trycka på sin FIDO2-nyckel och ange sin PIN-kod för varje SSH-anslutning. Det ger genuint tvåfaktorsautentisering — något du har (hårdvarunyckeln) och något du vet (PIN-koden).

Certifikatbaserad SSH-autentisering

Okej, nu till det som jag menar verkligen förändrar spelplanen för större organisationer. SSH-certifikat är ett kraftfullt alternativ till traditionella authorized_keys-filer. Istället för att distribuera publika nycklar till varje server skapar du en certifikatutfärdare (CA) som signerar användarnycklar. Servern litar på CA:n, och alla nycklar signerade av den accepteras automatiskt.

Varför certifikat istället för authorized_keys?

Fördelarna är många, och efter att ha jobbat med båda modellerna i produktion kan jag säga att skillnaden är markant:

  • Central hantering: Inga fler authorized_keys-filer att underhålla på hundratals servrar.
  • Automatisk utgång: Certifikat kan ha en begränsad giltighetstid — från timmar till dagar. När de löper ut krävs förnyelse.
  • Enkel revokering: Istället för att radera nycklar överallt lägger du till en nyckel i en revokationslista.
  • Principaler: Certifikaten kan binda en identitet till specifika användarnamn (principals), vilket begränsar åtkomsten.
  • Audit trail: Varje certifikat har ett unikt serienummer som kan spåras.

Sätta upp en SSH-certifikatutfärdare

Så här skapar du en komplett SSH CA-infrastruktur:

# Steg 1: Skapa en användar-CA-nyckel
# OBS: Förvara denna nyckel extremt säkert — den är kronjuvelen i din SSH-infrastruktur
mkdir -p /etc/ssh/ca
ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "SSH User CA $(date +%Y)"

# Steg 2: Skapa en värd-CA-nyckel (för att signera värdnycklar)
ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "SSH Host CA $(date +%Y)"

# Steg 3: Säkra CA-nycklarna
chmod 600 /etc/ssh/ca/user_ca /etc/ssh/ca/host_ca
chmod 644 /etc/ssh/ca/user_ca.pub /etc/ssh/ca/host_ca.pub

Signera användarnycklar

När en medarbetare behöver SSH-åtkomst signerar du deras publika nyckel med CA:n:

# Signera en användarnyckel med begränsad giltighet och specifika principals
ssh-keygen -s /etc/ssh/ca/user_ca \
    -I "[email protected]" \
    -n "anna,deploy" \
    -V +8h \
    -z $(date +%s) \
    anna_id_ed25519.pub

# Parametrar:
# -s : CA-nyckeln som signerar
# -I : Certifikat-identitet (för loggar och spårning)
# -n : Principals — vilka användarnamn som certifikatet gäller för
# -V : Giltighetstid (+8h = 8 timmar från nu)
# -z : Serienummer (unikt per certifikat)

# Verifiera det signerade certifikatet
ssh-keygen -L -f anna_id_ed25519-cert.pub

Utdata visar certifikatets detaljer — giltighetsperiod, principals och serienummer. Observera att certifikatet upphör att gälla automatiskt efter 8 timmar. Ingen manuell revokering behövs i normalfallet.

Konfigurera servern att lita på CA:n

# /etc/ssh/sshd_config - Certifikatbaserad autentisering

# Lita på användar-CA:n
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub

# Konfigurera AuthorizedPrincipalsFile
# Varje fil listar vilka principals som får logga in som den användaren
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

# Revokationslista (viktig!)
RevokedKeys /etc/ssh/ca/revoked_keys

Skapa sedan principals-filer för varje användare:

# Skapa katalog för principals
sudo mkdir -p /etc/ssh/auth_principals

# Anna får logga in som sig själv och som deploy-användaren
echo -e "anna\ndeploy" | sudo tee /etc/ssh/auth_principals/anna

# Deploy-användaren accepterar certifikat med "deploy"-principalen
echo "deploy" | sudo tee /etc/ssh/auth_principals/deploy

# Skapa en tom revokationslista
ssh-keygen -k -f /etc/ssh/ca/revoked_keys

Signera värdnycklar

Signera även dina servrars värdnycklar för att eliminera de där irriterande "Are you sure you want to connect?"-varningarna och — viktigare — förhindra man-in-the-middle-attacker:

# På CA-servern: signera serverns värdnyckel
ssh-keygen -s /etc/ssh/ca/host_ca \
    -I "webserver01.foretaget.se" \
    -h \
    -n "webserver01.foretaget.se,webserver01,10.10.1.10" \
    -V +52w \
    /etc/ssh/ssh_host_ed25519_key.pub

# -h : Anger att det är ett värdcertifikat (inte användarcertifikat)
# -n : Hostnames och IP-adresser som certifikatet gäller för
# -V : Giltigt i 52 veckor

Konfigurera servern att använda det signerade värdcertifikatet:

# /etc/ssh/sshd_config - Värdcertifikat
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Och på klientsidan, lita på värd-CA:n:

# ~/.ssh/known_hosts eller /etc/ssh/ssh_known_hosts
@cert-authority *.foretaget.se ssh-ed25519 AAAAC3Nz... SSH Host CA 2026

Automatisera certifikatförnyelse

Med kortlivade certifikat behövs automatiserad förnyelse. Här är ett skript som gör jobbet:

#!/bin/bash
# /usr/local/bin/ssh-cert-renew.sh
# Automatisk förnyelse av SSH-användarcertifikat

set -euo pipefail

CERT_DIR="$HOME/.ssh"
CA_SERVER="ca.foretaget.se"
CA_USER="cert-signer"
VALIDITY="+8h"

# Kontrollera om certifikatet snart löper ut (inom 1 timme)
if [ -f "$CERT_DIR/id_ed25519-cert.pub" ]; then
    EXPIRY=$(ssh-keygen -L -f "$CERT_DIR/id_ed25519-cert.pub" 2>/dev/null \
        | grep "Valid:" | grep -oP "to \K[0-9T:-]+")
    EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s 2>/dev/null || echo 0)
    NOW_EPOCH=$(date +%s)
    REMAINING=$(( EXPIRY_EPOCH - NOW_EPOCH ))

    if [ "$REMAINING" -gt 3600 ]; then
        echo "Certifikatet är fortfarande giltigt i $((REMAINING / 3600)) timmar."
        exit 0
    fi
fi

echo "Förnyar SSH-certifikat..."

# Skicka publik nyckel till CA-server för signering
scp "$CERT_DIR/id_ed25519.pub" \
    "$CA_USER@$CA_SERVER:/tmp/cert_request_$(whoami).pub"

# Signera på CA-servern (kräver lämplig behörighet)
ssh "$CA_USER@$CA_SERVER" \
    "ssh-keygen -s /etc/ssh/ca/user_ca \
    -I '$(whoami)@$(hostname)' \
    -n '$(whoami),deploy' \
    -V $VALIDITY \
    -z \$(date +%s) \
    /tmp/cert_request_$(whoami).pub && \
    rm /tmp/cert_request_$(whoami).pub"

# Hämta det signerade certifikatet
scp "$CA_USER@$CA_SERVER:/tmp/cert_request_$(whoami)-cert.pub" \
    "$CERT_DIR/id_ed25519-cert.pub"

echo "Certifikat förnyat. Giltigt $VALIDITY."
ssh-keygen -L -f "$CERT_DIR/id_ed25519-cert.pub" | grep "Valid:"

Lägg till detta i crontab för automatisk förnyelse:

# Förnya var 6:e timme (certifikat giltiga 8h ger 2h överlapp)
0 */6 * * * /usr/local/bin/ssh-cert-renew.sh >> /var/log/ssh-cert-renew.log 2>&1

Komplett sshd_config-härdning för 2026

Nu till den del som många väntat på. Här nedan presenterar vi en komplett, härdad sshd_config som samlar alla moderna säkerhetsprinciper på ett ställe. Varje sektion är kommenterad så att du förstår varför respektive inställning används.

# /etc/ssh/sshd_config — Härdad konfiguration 2026
# Testad med OpenSSH 10.0 på Ubuntu 24.04 LTS / RHEL 9

# === NÄTVERKSINSTÄLLNINGAR ===
# Lyssna enbart på specifika gränssnitt (inte 0.0.0.0)
ListenAddress 10.10.1.10
Port 22

# Använd enbart SSH-protokoll 2 (standard i moderna versioner)
# Protocol 2 behöver inte anges explicit i OpenSSH 10.0

# === AUTENTISERING ===
# Inaktivera root-inloggning helt
PermitRootLogin no

# Tillåt enbart pubkey-autentisering (inklusive FIDO2 och certifikat)
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

# Certifikatbaserad autentisering
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
RevokedKeys /etc/ssh/ca/revoked_keys

# FIDO2 och pubkey-algoritmer
PubkeyAcceptedAlgorithms [email protected],[email protected],ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

# Kräv minimum 3072-bitars RSA-nycklar
RequiredRSASize 3072

# Begränsa autentiseringsförsök
MaxAuthTries 3
LoginGraceTime 30

# === KRYPTOGRAFI ===
# Postkvant-nyckelutbyte först
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

# Starka chiffer
Ciphers [email protected],[email protected],[email protected]

# Starka MAC:ar (enbart encrypt-then-MAC)
MACs [email protected],[email protected]

# Värdnycklar — prioritera Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# === SÄKERHETSBEGRÄNSNINGAR ===
# Inaktivera all vidarebefordring
AllowTcpForwarding no
AllowStreamLocalForwarding no
X11Forwarding no
AllowAgentForwarding no
PermitTunnel no
GatewayPorts no

# Inaktivera onödiga funktioner
PermitUserEnvironment no
PermitUserRC no

# === SESSIONSHANTERING ===
# Aggressiv timeout för inaktiva sessioner
ClientAliveInterval 300
ClientAliveCountMax 2

# Begränsa samtidiga sessioner
MaxSessions 3
MaxStartups 10:30:60

# === LOGGNING ===
# Utförlig loggning för säkerhetsövervakning
LogLevel VERBOSE
SyslogFacility AUTH

# === ÅTKOMSTBEGRÄNSNING ===
# Tillåt enbart specifika grupper
AllowGroups ssh-users ssh-admins

# Motverka brute force med per-IP-begränsningar (via MaxStartups)
# Överväg att kombinera med fail2ban eller nftables-hastighetsbegränsning

# === BANDEROLL ===
# Visa en juridisk varning före autentisering
Banner /etc/ssh/banner.txt

Verifiera konfigurationen

Innan du startar om sshd — validera alltid konfigurationen först. Det här steget hoppar man inte över (lita på mig):

# Testa konfigurationen utan att starta om
sudo sshd -t

# Om inga fel visas, starta om SSH-tjänsten
sudo systemctl restart sshd

# Verifiera att sshd körs
sudo systemctl status sshd

# VIKTIGT: Ha alltid en aktiv session öppen som backup
# innan du startar om sshd — annars riskerar du att låsa ut dig själv!

Fail2ban och nftables: Skydda SSH mot brute force

Även med stark autentisering vill du begränsa brute force-attacker mot SSH. Dels för att minska brus i loggarna, dels för att minimera belastningen. Kombinera fail2ban med nftables så får du ett robust skydd:

# /etc/fail2ban/jail.d/sshd.conf
[sshd]
enabled = true
backend = systemd
port = ssh
filter = sshd
maxretry = 3
findtime = 600
bantime = 3600
banaction = nftables-multiport
banaction_allports = nftables-allports

# Längre bann för upprepade förbrytare
[sshd-aggressive]
enabled = true
backend = systemd
port = ssh
filter = sshd[mode=aggressive]
maxretry = 1
findtime = 86400
bantime = 604800

Komplettera med hastighetsbegränsning via nftables för skydd mot distribuerade attacker:

# nftables-regel för SSH-hastighetsbegränsning
table inet ssh_skydd {
    set ssh_blockerad {
        type ipv4_addr
        flags timeout
        timeout 1h
    }

    chain input {
        type filter hook input priority -1; policy accept;

        # Blockera IP-adresser i blockeringslistan
        ip saddr @ssh_blockerad drop

        # Begränsa nya SSH-anslutningar till 5 per minut per IP
        tcp dport 22 ct state new \
            meter ssh_meter { ip saddr limit rate 5/minute burst 3 packets } \
            accept

        # Lägg till överträdare i blockeringslistan
        tcp dport 22 ct state new \
            add @ssh_blockerad { ip saddr timeout 1h } \
            log prefix "SSH-BRUTE: " drop
    }
}

Övervakning och logganalys

En härdad SSH-konfiguration är bara halva jobbet. Du behöver också övervaka SSH-aktivitet kontinuerligt för att upptäcka misstänkta händelser i tid.

Strukturerad SSH-loggning med journald

# Visa SSH-specifika loggar
journalctl -u sshd --since "1 hour ago" --no-pager

# Filtrera på misslyckade inloggningar
journalctl -u sshd --since today | grep -i "failed\|invalid\|refused"

# Visa alla certifikatbaserade inloggningar
journalctl -u sshd --since today | grep "certificate"

# Exportera till JSON för vidare analys
journalctl -u sshd --since "24 hours ago" -o json > /var/log/ssh_audit.json

Enkel övervakningsskript

Här är ett praktiskt skript som analyserar SSH-loggar och sammanställer en daglig rapport:

#!/bin/bash
# /usr/local/bin/ssh-monitor.sh
# Daglig SSH-säkerhetsrapport

RAPPORT="/tmp/ssh_rapport_$(date +%Y%m%d).txt"
MOTTAGARE="[email protected]"

{
    echo "=== SSH SÄKERHETSRAPPORT $(date) ==="
    echo ""

    echo "--- Misslyckade inloggningsförsök (senaste 24h) ---"
    journalctl -u sshd --since "24 hours ago" --no-pager \
        | grep -c "Failed" || echo "0"

    echo ""
    echo "--- Topp 10 IP-adresser med misslyckade försök ---"
    journalctl -u sshd --since "24 hours ago" --no-pager \
        | grep "Failed" \
        | grep -oP "from \K[0-9.]+" \
        | sort | uniq -c | sort -rn | head -10

    echo ""
    echo "--- Lyckade inloggningar ---"
    journalctl -u sshd --since "24 hours ago" --no-pager \
        | grep "Accepted" \
        | awk '{print $1, $2, $3, $9, $11}'

    echo ""
    echo "--- Certifikatlöpningstider (inom 24h) ---"
    for cert in /etc/ssh/*-cert.pub; do
        if [ -f "$cert" ]; then
            echo "$cert:"
            ssh-keygen -L -f "$cert" 2>/dev/null | grep "Valid:"
        fi
    done

    echo ""
    echo "--- Aktuellt fail2ban-status ---"
    sudo fail2ban-client status sshd 2>/dev/null || echo "fail2ban ej aktiv"

} > "$RAPPORT"

# Skicka rapport via e-post (kräver mailutils)
if command -v mail &>/dev/null; then
    mail -s "SSH Säkerhetsrapport $(date +%Y-%m-%d)" "$MOTTAGARE" < "$RAPPORT"
fi

echo "Rapport sparad: $RAPPORT"

Säkerhetschecklista: SSH-härdning 2026

Så, låt oss sammanfatta. Här är en komplett checklista som du kan arbeta igenom för att säkerställa att din SSH-infrastruktur följer moderna säkerhetsprinciper:

  1. Uppdatera till OpenSSH 10.0+ på alla servrar och klienter för att få postkvant-nyckelutbyte som standard.
  2. Verifiera postkvant-kex med ssh -vv och bekräfta att mlkem768x25519-sha256 används.
  3. Implementera FIDO2-hårdvarunycklar för alla administratörer och privilegierade konton. Kräv verify-required för extra säkerhet.
  4. Sätt upp en SSH CA för certifikatbaserad autentisering. Sluta med manuell hantering av authorized_keys.
  5. Använd kortlivade certifikat med automatiserad förnyelse. 8 timmar är en bra startpunkt för dagligt arbete.
  6. Ta bort alla DSA- och ECDSA-nycklar och migrera till Ed25519.
  7. Kräv minst 3072-bitars RSA med RequiredRSASize 3072 för system som fortfarande använder RSA.
  8. Inaktivera lösenordsautentisering helt — PasswordAuthentication no.
  9. Inaktivera onödig vidarebefordring: TCP, StreamLocal, X11 och agentvidarebefordring.
  10. Konfigurera fail2ban med nftables-backend och aggressiva banntider för upprepade förbrytare.
  11. Aktivera VERBOSE-loggning och implementera daglig logggranskning.
  12. Kör ssh-audit regelbundet för att identifiera konfigurationsavvikelser.
  13. Begränsa SSH-åtkomst till specifika grupper med AllowGroups.
  14. Ha alltid en backup-session öppen när du gör ändringar i sshd_config. Seriöst — den regeln har räddat mig mer än en gång.

Sammanfattning och nästa steg

SSH-säkerhet 2026 handlar om att ligga steget före i ett hotlandskap som förändras snabbt. Med kvantdatorer vid horisonten, allt mer sofistikerade malware-kampanjer och ökade compliance-krav räcker det inte längre med bara lösenordslösa SSH-nycklar och en ändrad port.

De tre pelarna i modern SSH-säkerhet är:

  • Postkvant-kryptografi via OpenSSH 10.0:s ML-KEM-baserade nyckelutbyte skyddar mot framtida kvantdatorattacker redan idag.
  • FIDO2-hårdvarunycklar eliminerar risken för nyckelstöld genom att säkerställa att den privata nyckeln aldrig lämnar den fysiska enheten.
  • Certifikatbaserad autentisering ger central hantering, automatisk utgång och enkel revokering — helt avgörande för organisationer med mer än en handfull servrar.

Kombinera dessa tre med en noggrant härdad sshd_config, proaktiv övervakning och regelbunden granskning med verktyg som ssh-audit, och du har en SSH-infrastruktur som är robust nog att möta hoten under 2026 och framåt.

Som nästa steg rekommenderar vi att du integrerar SSH-certifikathanteringen med din befintliga identitets- och åtkomsthantering (IAM), utforskar OIDC-baserade SSH-certifikat för sömlös integration med single sign-on, och överväger session recording för fullständig spårbarhet av privilegierade SSH-sessioner. Det är den sortens investeringar som betalar sig snabbt.

Om Författaren Editorial Team

Our team of expert writers and editors.