Adgangskodelogin over SSH er den største åbne flade på en almindelig server. Mod den er både Fail2ban og alle tærskler magtesløse: tusind adresser med ét forsøg i timen når aldrig nogen grænse, og de vil fortsætte præcis så længe, gætteri overhovedet er muligt. Nøgler fjerner selve muligheden, og det er den eneste indstilling på hele hærdningslisten, der ændrer situationen grundlæggende.

Det eneste skræmmende er at slå adgangskoden fra og blive stående udenfor. Nedenfor følger en rækkefølge, hvor det ikke kan ske.

Nøglen

Genereres på din egen maskine, ikke på serveren:

ssh-keygen -t ed25519 -C "arbejdslaptop"

ed25519 i stedet for RSA — kortere, hurtigere og uden spørgsmål om nøglelængde. RSA er kun nødvendig, hvis du skal forbinde til noget meget gammelt; så -t rsa -b 4096.

En adgangsfrase på nøglen er værd at sætte: nøglefilen kan blive stjålet fra laptoppen, og uden adgangsfrase virker den med det samme. Du skal ikke skrive den hver gang — det klarer ssh-agent, og på macOS og de fleste desktop-Linux kører den allerede.

Kopiering til serveren med én kommando, mens adgangskoden stadig virker:

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

Findes ssh-copy-id ikke, tilføjes indholdet af .pub-filen som en linje i ~/.ssh/authorized_keys på serveren. Rettighederne er vigtige: mappen .ssh skal være 700, filen 600 og ejeren brugeren selv. Med andre rettigheder nægter sshd stille at læse filen, og det er den hyppigste grund til, at »nøglen ikke virker«.

Kontrollen der afgør alt

Før du slår noget som helst fra — åbn en anden forbindelse uden at lukke den første:

ssh -o PasswordAuthentication=no user@203.0.113.25

Flaget forbyder klienten at falde tilbage på adgangskode — lykkes loginet, skete det altså med nøgle. Før den kommando går igennem, må du ikke gå videre til næste trin. Og den første forbindelse lukker vi ikke, før alt er færdigt: gennem den repareres alt, hvad der kan ødelægges.

Frakoblingen og en ikke-indlysende faldgrube

Indstillingerne lægger vi i en separat fil, så pakkeopdateringen ikke overskriver dem. Men filnavnet betyder noget:

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

Sagen er, at OpenSSH bruger den først fundne værdi for en parameter, ikke den sidste, som det er næsten alle andre steder. Filerne i sshd_config.d læses i alfabetisk orden, og Ubuntus sky-images lægger 50-cloud-init.conf derind, som ofte indeholder PasswordAuthentication yes. Din fil med nummer 90 gør så ingenting: indstillingen ser ud til at være udført, men adgangskoden virker stadig. Deraf nummer 10 — den læses tidligere.

Hvad der rent faktisk blev resultatet, behøver du ikke gætte:

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

Kommandoen udskriver den gældende konfiguration efter alle inkluderinger. Stol på den og ikke på indholdet af filerne.

Så syntakskontrol og blød genindlæsning af tjenesten:

sudo sshd -t && sudo systemctl reload ssh

sshd -t er obligatorisk: en tastefejl i konfigurationen ved restart efterlader tjenesten nede og dig udenfor. reload afbryder desuden ikke åbne sessioner.

Ubuntu 24.04: porten ændres ikke der

En særlig faldgrube i friske Ubuntu: sshd startes der via en systemd-socket. Linjen Port i sshd_config gør i den tilstand ingenting — det er socketen, der lytter, ikke dæmonen. Skal du skifte port, er det den, du ændrer:

sudo systemctl edit ssh.socket

og angiver ListenStream= (tom værdi nulstiller den forrige) med den nye port. Symptomet, der afslører det: konfigurationen er ændret, tjenesten genstartet, og serveren svarer stadig på 22.

Apropos portskift: som beskyttelse virker det ikke — scannere finder tjenesten på enhver port i løbet af minutter. Den eneste effekt er, at der bliver mere stille i logfilerne, da massegætteriet kun går mod 22. Det er praktisk, men bland det ikke sammen med sikkerhed.

Hvem der overhovedet må logge ind

En nyttig tilføjelse er en udtrykkelig liste:

AllowUsers deploy admin

Alt, der ikke er opregnet, afvises allerede før nøglen kontrolleres. Det dækker samtidig det tilfælde, hvor en pakke opretter en systembruger med skal og hjemmemappe.

Reservevejen ind

Én nøgle på én laptop er ét enkelt fejlpunkt. Disken dør, laptoppen mistes, og serveren bliver utilgængelig for altid. Rimeligt minimum:

  • en anden nøgle fra en anden enhed i authorized_keys;
  • en kopi af den private nøgle i en adgangskodemanager eller på en krypteret USB-nøgle;
  • kontrolleret konsoladgang hos hostingudbyderen — VNC eller seriel. Kontrolleret betyder, at du har logget ind der mindst én gang, ikke at »der er en knap et sted i panelet«.

Benyt samtidig lejligheden til at se, hvad der allerede ligger i authorized_keys — både hos din bruger og hos root. En fremmed nøgle der overlever ethvert adgangskodeskift og forbliver en fungerende adgang.

Bagefter

Adgangskodegætteriet forsvinder ikke, det bliver blot meningsløst: i logfilerne står tusindvis af Failed password tilbage, og ingen af dem kan ende i succes. Det, du bør se på nu, er i stedet de vellykkede logins: fra hvilken adresse, som hvilken bruger, på hvilket tidspunkt. Et vellykket nøglelogin fra en ukendt adresse er en langt vigtigere hændelse end en million mislykkede forsøg og betydeligt sværere at opdage i den almindelige strøm. Det er præcis det billede, demonstrationssiden nedenfor viser.