Passordinnlogging over SSH er den største åpne flaten på en vanlig server. Mot den er både Fail2ban og alle terskler maktesløse: tusen adresser med ett forsøk i timen når aldri noen grense, og de vil fortsette nøyaktig så lenge gjetting overhodet er mulig. Nøkler fjerner selve muligheten, og det er den eneste innstillingen i hele herdingslisten som endrer situasjonen i bunn og grunn.

Det eneste skremmende er å slå av passordet og bli stående utenfor. Nedenfor følger en rekkefølge der det ikke kan skje.

Nøkkelen

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

ssh-keygen -t ed25519 -C "arbeidslaptop"

ed25519 i stedet for RSA — kortere, raskere og uten spørsmål om nøkkellengde. RSA trengs bare hvis du skal koble deg til noe svært gammelt; da -t rsa -b 4096.

Passfrase på nøkkelen er verdt å sette: nøkkelfilen kan bli stjålet fra laptopen, og uten passfrase virker den umiddelbart. Du må ikke skrive den hver gang — det tar ssh-agent seg av, og på macOS og de fleste skrivebords-Linux kjører den allerede.

Kopiering til serveren med én kommando, mens passordet ennå virker:

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

Finnes ikke ssh-copy-id, legges innholdet i .pub-filen til som en linje i ~/.ssh/authorized_keys på serveren. Rettighetene er viktige: katalogen .ssh skal være 700, filen 600 og eieren brukeren selv. Med andre rettigheter nekter sshd stille å lese filen, og det er den vanligste grunnen til at «nøkkelen ikke virker».

Kontrollen som avgjør alt

Før du slår av noe som helst — åpne en andre forbindelse uten å lukke den første:

ssh -o PasswordAuthentication=no user@203.0.113.25

Flagget forbyr klienten å falle tilbake på passord — lykkes innloggingen, skjedde den altså med nøkkel. Før den kommandoen går gjennom, kan du ikke gå videre til neste steg. Og den første forbindelsen lukker vi ikke før alt er ferdig: gjennom den repareres alt som kan ødelegges.

Avslåingen og en ikke opplagt felle

Innstillingene legger vi i en egen fil, slik at pakkeoppdateringen ikke overskriver dem. Men filnavnet betyr noe:

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 er at OpenSSH bruker den først påtrufne verdien for en parameter, ikke den siste, slik det er nesten overalt ellers. Filene i sshd_config.d leses i alfabetisk rekkefølge, og Ubuntus skyavbildninger legger dit 50-cloud-init.conf, som ofte inneholder PasswordAuthentication yes. Filen din med nummer 90 gjør da ingenting: innstillingen ser ut til å være gjort, men passordet virker fortsatt. Derav nummer 10 — den leses tidligere.

Hva som faktisk ble resultatet, trenger du ikke gjette:

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

Kommandoen skriver ut den gjeldende konfigurasjonen etter alle inkluderinger. Stol på den og ikke på innholdet i filene.

Så syntakskontroll og myk omlasting av tjenesten:

sudo sshd -t && sudo systemctl reload ssh

sshd -t er obligatorisk: en skrivefeil i konfigurasjonen ved restart etterlater tjenesten nede og deg utenfor. reload bryter dessuten ikke åpne økter.

Ubuntu 24.04: porten endres ikke der

En egen felle i ferske Ubuntu: sshd startes der via en systemd-socket. Linjen Port i sshd_config gjør i den modusen ingenting — det er socketen som lytter, ikke daemonen. Skal du bytte port, er det den du endrer:

sudo systemctl edit ssh.socket

og angir ListenStream= (tom verdi nullstiller den forrige) med den nye porten. Symptomet som avslører det: konfigurasjonen er endret, tjenesten startet på nytt, og serveren svarer fortsatt på 22.

Apropos portbytte: som beskyttelse virker det ikke — skannere finner tjenesten på hvilken som helst port i løpet av minutter. Den eneste effekten er at det blir stillere i loggene, siden massegjettingen bare går mot 22. Det er praktisk, men ikke bland det med sikkerhet.

Hvem som i det hele tatt får logge inn

Et nyttig tillegg er en uttrykkelig liste:

AllowUsers deploy admin

Alt som ikke er listet opp, avvises allerede før nøkkelen kontrolleres. Det dekker samtidig tilfellet der en pakke oppretter en systembruker med skall og hjemmekatalog.

Reserveveien inn

Én nøkkel på én laptop er ett enkelt feilpunkt. Disken dør, laptopen mistes, og serveren blir utilgjengelig for alltid. Rimelig minimum:

  • en andre nøkkel fra en annen enhet i authorized_keys;
  • en kopi av den private nøkkelen i en passordbehandler eller på en kryptert minnepinne;
  • kontrollert konsolltilgang hos hostingleverandøren — VNC eller seriell. Kontrollert betyr at du har logget inn der minst én gang, ikke at «det finnes en knapp et sted i panelet».

Benytt samtidig anledningen til å se hva som allerede ligger i authorized_keys — både hos brukeren din og hos root. En fremmed nøkkel der overlever ethvert passordbytte og forblir en fungerende tilgang.

Etterpå

Passordgjettingen forsvinner ikke, den blir bare meningsløs: i loggene blir det stående tusenvis av Failed password, og ingen av dem kan ende i suksess. Det du bør se på nå, er i stedet de vellykkede innloggingene: fra hvilken adresse, som hvilken bruker, på hvilket tidspunkt. En vellykket nøkkelinnlogging fra en ukjent adresse er en langt viktigere hendelse enn en million mislykkede forsøk, og betydelig vanskeligere å oppdage i den alminnelige strømmen. Det er nettopp det bildet demonstrasjonssiden nedenfor viser.