Port 22 är en av de mest attackerade portarna på internet. Kör ni en VPS med publik IP pågår brute force-försök mot SSH kontinuerligt, från hundratals IP:er i minuten. Det är ingen personlig vendetta mot er. Det är bakgrundsstrålning.

Den här guiden går igenom vad ni bör göra för att härda SSH på en VPS. Tidsåtgång: ungefär 20 minuter. Målgrupp: Linux-admin som driftar egen VPS (hos Adminor eller annan leverantör).

Varför det spelar roll

SSH med lösenordsautentisering är nästan alltid det svagaste stället på en annars härdad server. En angripare behöver inte exploatera sårbarheter. De behöver bara gissa rätt lösenord. Bot-nätverk prövar tusentals lösenord per minut mot tusentals servrar samtidigt.

Default-installationer av Debian, Ubuntu och de flesta Linux-distributioner tillåter lösenords-login mot root. På publik IP är det en tidsfråga innan någon kommer in.

Vad ni ska uppnå

Efter den här guiden:

  • Endast nyckelbaserad autentisering fungerar
  • Root kan inte logga in via SSH alls
  • Fail2ban blockar brute force-försök automatiskt
  • SSH lyssnar på icke-standardport (valfritt, ger signifikant mindre scan-brus)
  • UFW eller nftables släpper bara in SSH från kända nätverk (valfritt, för admin-servrar)

Steg 1 — Generera SSH-nyckel (om ni inte redan har en)

På er lokala maskin (inte på servern):

ssh-keygen -t ed25519 -C "[email protected]"

Tryck Enter för default-sökväg. Sätt en passphrase — det är ett lösenord som skyddar nyckeln om er laptop blir stulen.

ED25519 är standard 2026. RSA fungerar men är äldre. Undvik DSA och ECDSA.

Resultat: två filer i ~/.ssh/:

  • id_ed25519 — privat nyckel (delas aldrig)
  • id_ed25519.pub — publik nyckel (går ut på servrarna)

Steg 2 — Kopiera publik nyckel till servern

ssh-copy-id anvä[email protected]

Första gången använder ni lösenord. Efter detta fungerar nyckel-login.

Om ssh-copy-id inte finns (Windows, macOS-setup etc.):

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

Testa att nyckel-login fungerar genom att öppna en ny terminal och logga in. Om ni inte får prompt om lösenord: klart.

Steg 3 — Skapa en non-root-användare (om ni loggar in som root)

Logga in som root, skapa en vanlig användare och ge sudo-rättigheter:

adduser deploy
usermod -aG sudo deploy      # Debian/Ubuntu
# eller
usermod -aG wheel deploy     # RHEL/AlmaLinux/Rocky

Kopiera SSH-nyckeln till den nya användaren:

mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Öppna en ny terminal och verifiera att ni kan logga in som deploy-användaren:

ssh [email protected]
sudo -i   # ska fungera

Stäng inte er nuvarande root-session förrän ni är säkra på att non-root-inloggning fungerar.

Steg 4 — Härda sshd_config

Redigera /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Sätt följande värden (skapa raderna om de inte finns, ta bort kommentar-tecken # om de finns):

# Ingen lösenordsautentisering
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM no

# Ingen root-login
PermitRootLogin no

# Bara ed25519 och rsa (inga DSA)
PubkeyAuthentication yes

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

# Valfritt: byt port
# Port 22022

# Valfritt: begränsa till specifika användare
# AllowUsers deploy alice

Spara filen, testa konfigurationen och ladda om SSH:

sudo sshd -t                    # testar syntax
sudo systemctl restart sshd

Viktigt: innan ni stänger er nuvarande SSH-session, öppna en ny terminal och verifiera att ni kan logga in med nyckel. Om något är fel har ni fortfarande den gamla sessionen öppen för att fixa det.

Steg 5 — Installera fail2ban

Fail2ban läser loggfiler och blockerar IP-adresser som gör för många misslyckade inloggningsförsök.

Debian/Ubuntu:

sudo apt update
sudo apt install fail2ban

RHEL/AlmaLinux:

sudo dnf install epel-release
sudo dnf install fail2ban

Skapa en lokal config:

sudo nano /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = 22
# Om ni bytt port:
# port = 22022

Starta fail2ban:

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

Kontrollera status:

sudo fail2ban-client status sshd

Efter några timmar på publik IP kommer ni se banned IPs i listan.

Steg 6 — Byt SSH-port (valfritt)

Att flytta SSH från port 22 till exempelvis 22022 stoppar inte en riktad angripare, men eliminerar 99% av bot-brus. Det gör loggarna renare och fail2ban mindre belastat.

I /etc/ssh/sshd_config:

Port 22022

Öppna den nya porten i brandväggen innan ni startar om SSH:

sudo ufw allow 22022/tcp
# alternativt
sudo firewall-cmd --permanent --add-port=22022/tcp && sudo firewall-cmd --reload

Starta om SSH:

sudo systemctl restart sshd

Verifiera från ny terminal:

ssh -p 22022 [email protected]

När det fungerar: stäng port 22 i brandväggen.

Steg 7 — UFW/brandvägg

Om servern bara ska vara tillgänglig från kända IP-adresser (t.ex. en bastion-host eller kontorsnät):

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.0/24 to any port 22022
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Viktigt: se till att ni inte låser ut er själv. Kör kommandona i en tmux eller screen-session så ni har en fallback.

Bonus — 2FA på SSH

För särskilt känsliga servrar kan ni lägga till TOTP (Google Authenticator) ovanpå nyckelautentisering. Sätt upp via libpam-google-authenticator. Det är dock rätt ovanligt för typiska produktionsservrar — nyckel-only + fail2ban är tillräckligt i de flesta fall.

Vad EASM upptäcker på SSH

Om ni kör kontinuerlig övervakning via pentesting.se flaggas följande som findings på er SSH-konfiguration:

  • Lösenords-autentisering aktiverad
  • Root-login tillåten
  • Svaga cipher suites
  • Gamla OpenSSH-versioner med kända CVE:er
  • SSH exponerad på icke-standardport utan motsvarande brandväggsregel

Se EASM-guiden för uppsättning.

Vanliga frågor

Räcker fail2ban utan nyckel-only?

Nej. Fail2ban saktar ner brute force men stoppar inte den. Med ett tillräckligt dåligt lösenord och tålamod kommer någon in. Nyckel-only är den verkliga skyddsåtgärden.

Kan jag fortfarande logga in om jag tappar privata nyckeln?

Nej. Säkerhetskopiera alltid er privata nyckel (krypterad, off-site). Alternativt ha flera authorized keys så ni inte hamnar i låst läge.

Fungerar det här för Adminor-managed VPS?

Ja. Om ni har en managed VPS hos oss är konfigurationen redan gjord från start. Den här guiden är för er som driftar egen VPS och vill göra det själv.

Varför ed25519 och inte RSA?

ED25519 är snabbare, kortare och bygger på modernare elliptisk kurv-kryptografi. RSA fungerar fortfarande, men nyckellängden (4096 bit) är klumpig. ED25519-nycklar är 68 tecken — RSA 4096 är över 700. Båda är säkra 2026.

Kan jag automatisera det här?

Ja. Ansible har färdiga roller för SSH-härdning. Adminors interna drift använder bland annat dev-sec/ssh-hardening som referens.

Läs mer

Nästa steg

Om ni kör en VPS hos oss och vill ha hjälp med SSH-härdning, hör av er via kontaktsidan. För managed VPS ingår det i tjänsten.