Lösenordsinloggning över SSH är den största öppna ytan på en vanlig server. Mot den är både Fail2ban och alla trösklar maktlösa: tusen adresser med ett försök i timmen når aldrig någon gräns, och de kommer att fortsätta precis så länge gissning över huvud taget är möjlig. Nycklar tar bort själva möjligheten, och det är den enda inställningen i hela härdningslistan som ändrar läget i grunden.

Det enda skrämmande är att stänga av lösenordet och bli kvar utanför. Nedan följer en ordning där det inte kan hända.

Nyckeln

Genereras på din egen maskin, inte på servern:

ssh-keygen -t ed25519 -C "arbetslaptop"

ed25519 i stället för RSA — kortare, snabbare och utan frågor om nyckellängd. RSA behövs bara om du ska ansluta till något mycket gammalt; då -t rsa -b 4096.

Lösenfras på nyckeln är värt att sätta: nyckelfilen kan bli stulen från laptopen, och utan lösenfras fungerar den omedelbart. Du behöver inte skriva den varje gång — det sköter ssh-agent, och på macOS och de flesta skrivbords-Linux är den redan igång.

Kopiering till servern med ett kommando, medan lösenordet ännu fungerar:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

Om ssh-copy-id inte finns läggs innehållet i .pub-filen till som en rad i ~/.ssh/authorized_keys på servern. Rättigheterna är viktiga: katalogen .ssh ska vara 700, filen 600 och ägaren användaren själv. Med andra rättigheter vägrar sshd tyst att läsa filen, och det är den vanligaste orsaken till att ”nyckeln inte fungerar”.

Kontrollen som avgör allt

Innan du stänger av något — öppna en andra anslutning utan att stänga den första:

ssh -o PasswordAuthentication=no user@203.0.113.25

Flaggan förbjuder klienten att falla tillbaka på lösenord — om inloggningen lyckas skedde den alltså med nyckel. Innan det kommandot går igenom får du inte gå vidare till nästa steg. Och den första anslutningen stänger vi inte förrän allt är klart: genom den lagas allt som går att ha sönder.

Avstängningen och en icke uppenbar fälla

Inställningarna lägger vi i en egen fil så att paketuppdateringen inte skriver över dem. Men filnamnet spelar roll:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

Saken är den att OpenSSH använder det först påträffade värdet för en parameter, inte det sista som nästan överallt annars. Filerna i sshd_config.d läses i bokstavsordning, och Ubuntus molnavbildningar lägger dit 50-cloud-init.conf, som ofta innehåller PasswordAuthentication yes. Din fil med nummer 90 gör då ingenting: inställningen ser ut att vara gjord, men lösenordet fungerar fortfarande. Därav nummer 10 — den läses tidigare.

Vad som faktiskt blev resultatet behöver du inte gissa:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

Kommandot skriver ut den gällande konfigurationen efter alla inkluderingar. Lita på den och inte på filernas innehåll.

Sedan syntaxkontroll och mjuk omladdning av tjänsten:

sudo sshd -t && sudo systemctl reload ssh

sshd -t är obligatoriskt: ett stavfel i konfigurationen vid restart lämnar tjänsten nere och dig utanför. reload bryter dessutom inte öppna sessioner.

Ubuntu 24.04: porten ändras inte där

En egen fälla i färska Ubuntu: sshd startas där via en systemd-socket. Raden Port i sshd_config gör i det läget ingenting — det är socketen som lyssnar, inte demonen. Ska du byta port är det den du ändrar:

sudo systemctl edit ssh.socket

och anger ListenStream= (tomt värde nollställer det tidigare) med den nya porten. Symtomet som avslöjar det: konfigurationen är ändrad, tjänsten omstartad, och servern svarar fortfarande på 22.

Apropå portbyte: som skydd fungerar det inte — skannrar hittar tjänsten på vilken port som helst på några minuter. Den enda effekten är att det blir tystare i loggarna, eftersom massgissningen bara går mot 22. Det är bekvämt, men blanda inte ihop det med säkerhet.

Vem som alls får logga in

Ett nyttigt tillägg är en uttrycklig lista:

AllowUsers deploy admin

Allt som inte räknas upp avvisas redan innan nyckeln kontrolleras. Det täcker samtidigt fallet där något paket skapar en systemanvändare med skal och hemkatalog.

Reservväg in

En nyckel på en laptop är en enda felpunkt. Disken dör, laptopen tappas bort, och servern blir onåbar för alltid. Rimligt minimum:

  • en andra nyckel från en annan enhet i authorized_keys;
  • en kopia av den privata nyckeln i en lösenordshanterare eller på ett krypterat USB-minne;
  • kontrollerad konsolåtkomst hos hostingleverantören — VNC eller seriell. Kontrollerad betyder att du loggat in där minst en gång, inte att ”det finns en knapp någonstans i panelen”.

Passa samtidigt på att se vad som redan ligger i authorized_keys — både hos din användare och hos root. En främmande nyckel där överlever varje lösenordsbyte och förblir en fungerande åtkomst.

Efteråt

Lösenordsgissningen försvinner inte, den blir bara meningslös: i loggarna kommer tusentals Failed password att stå kvar, varav ingen kan sluta i framgång. Det du bör titta på nu är i stället de lyckade inloggningarna: från vilken adress, som vilken användare, vid vilken tid. En lyckad nyckelinloggning från en okänd adress är en långt viktigare händelse än en miljon misslyckade försök, och betydligt svårare att upptäcka i det allmänna flödet. Det är precis den bilden demonstrationssidan nedan visar.