linuz Linux, på enkelt språk

SSH — herding av serveren

En gjennomgang av sshd-herding på enkelt språk: kun nøkkelinnlogging, begrensning av brukere, portspørsmålet, validerte omstarter og logger — sikring av maskinen du kobler til.

På denne siden

Guiden SSH — fra passord til nøkler sikret din side av forbindelsen: nøkler i stedet for passord, en agent, kallenavn for maskinene du når. Denne guiden handler om den andre enden — maskinen som tar imot tilkoblinger. En leid server eller en Raspberry Pi eksponert mot internett blir bedt om å bevise identiteten sin tusenvis av ganger i døgnet, av automatiserte skript som gjetter passord. Herding er måten du slutter å svare på.

Alt her er verifisert på engangscontainere med Ubuntu 26.04, Fedora 44 og Arch, som kjører OpenSSH 10.2–10.5, fra innsiden. Ingenting i denne guiden krever noe utover maskinen du herder og klienten du leser dette på.

Den ene regelen før enhver endring

SSH har ingen «glemt passord»-e-post. Bryter du SSH-serveren på avstand, er veien inn igjen den konsollen leverandøren din gir deg — regn med at den er treg og irriterende. På en Raspberry Pi er nødløsningen i stedet et tastatur og en skjerm. Derfor følger alle endringer i denne guiden samme ritual:

  1. Endre konfigurasjonen.
  2. Valider den med sshd -t før du starter noe på nytt.
  3. Start SSH-tjenesten på nytt.
  4. Bevis at det nye oppsettet virker ved å logge inn fra en ny terminal, mens den gamle sesjonen fortsatt står åpen.
  5. Først deretter lukker du den gamle sesjonen.

Grunnen til steg 4 er at en eksisterende sesjon overlever en omstart. Dette ble testet direkte: en sesjon fikk stå å kjøre en kommando på tolv sekunder, tjenesten ble startet på nytt under den, og kommandoen ble ferdig med utdataen i behold. Den gjeldende tilkoblingen er sikkerhetstauen din. Hold den til den nye veien inn er bevist.

Og hvis innlogginga i steg 4 feiler, er trekket bakover, ikke framover: angre endringen, sshd -t, start på nytt, og bekreft at den gamle oppførselen er tilbake — alt fra sesjonen som fortsatt virker. Finn årsaken, og prøv igjen. Brukerbegrensningen lenger ned er det klassiske stedet dette redder deg: én feilstavet bruker der nekter selv nøkkelinnehavere adgang.

Der konfigurasjonen ligger

Serverinnstillingene ligger i /etc/ssh/sshd_config, en ren tekstfil. Rediger den med sudo nano /etc/ssh/sshd_config. Fila består mest av kommentarer. Linjene som betyr noe, starter med et nøkkelord og en verdi.

Etter hver endring, valider før du starter på nytt:

$ sudo sshd -t

Stillhet og exit-kode null betyr at syntaksen er i orden. En skrivefeil gir en feilmelding som navngir linja:

/etc/ssh/sshd_config: line 146: Bad configuration option: Portr
/etc/ssh/sshd_config: terminating, 1 bad configuration options

Denne utdataen kom fra å legge til Portr 22 — én ekstra bokstav. Merk hva valideringen nettopp hindret: en server som nekter å starte. For å se konfigurasjonen serveren faktisk kjører med, ikke bare teste syntaksen:

$ sudo sshd -T | grep -i passwordauthentication
passwordauthentication yes

Hvis den testen én gang er uenig med endringen din (den sier yes etter at du satte no), er det en annen fil som vinner. Serveren bruker den første verdien den leser, og hovedfila kan trekke inn ekstra konfigfiler fra /etc/ssh/sshd_config.d/ nesten helt øverst. Se etter en Include-linje i /etc/ssh/sshd_config og sjekk den mappen.

Én merknad om navn: tjenesten heter ssh på Ubuntu og sshd på Fedora og Arch, så omstartskommandoen er en annen. På Arch er ikke serveren forhåndsinstallert — sudo pacman -S openssh installerer den; Fedora leverer den i basissystemet, og Ubuntu håndterer den ved installasjon i stedet for via metapakkene:

$ sudo systemctl restart ssh      # Ubuntu
$ sudo systemctl restart sshd     # Fedora, Arch

Konfigurasjonsdirektivene oppfører seg likt på begge. Det som skiller, er tjenestenavnet — og én Ubuntu-spesifikk detalj du møter i portdelen.

Kun nøkkel — hovedsakelen

Hvis du fulgte klientguiden, ligger nøkkelen din alt på serveren (ssh-copy-id la den der), og nøkkelinnlogging virker. Sjekk det med egne øyne før du går videre: åpne en ny terminal, logg inn med nøkkelen, uten passord. Feiler den innlogginga, stopp her og fiks det først.

Åpne /etc/ssh/sshd_config og sett:

PasswordAuthentication no

Så valider, start på nytt og test — i den rekkefølgen. Med passordautentisering slått av nektes et passordforsøk før det i det hele tatt spørres etter et passord, og klienten viser det:

sshguide@localhost: Permission denied (publickey).

Ordet publickey i parentes er hele listen over innloggingsmetoder serveren fortsatt tilbyr — før endringen viste samme forsøk (publickey,password). Og serveren forklarer ikke hvorfor en innlogging ble nektet, verken for deg eller for noen som gjetter. Stillheten er en fordel.

Mens du først er i fila, ta en titt på root. Standardinnstillingen, PermitRootLogin prohibit-password, blokkerer allerede root-innlogging med passord. Å skrive det eksplisitt lukker spørsmålet for godt:

PermitRootLogin no

Med no kan root ikke logge inn over SSH i det hele tatt — du logger inn som deg selv og bruker sudo til administrasjonsarbeid, akkurat som kapittel 5 lærte deg. På en localhost-testrigg ble root-passordforsøk avvist under begge innstillingene, med samme melding uansett.

Begrens hvem som kan logge inn

AllowUsers gjør innloggingsregelen om til en eksplisitt liste. Alle som ikke står på den, nektes før autentiseringen i det hele tatt begynner:

AllowUsers yourname

Start på nytt, og et innloggingsforsøk fra en hvilken som helst annen konto støter på samme Permission denied-vegg. Den tillatte kontoen fortsetter å fungere. Hvis flere personer drifter maskinen, list dem alle opp atskilt med mellomrom, eller bruk AllowGroups med en gruppe (kapittel 5 viste hvordan grupper fungerer).

Effekten er liten, men reell: kontoer du aldri opprettet, kan ikke logges inn på, og et skript som gjetter admin- eller root-passord sløser bort tiden sin på en server som har sluttet å lytte etter de navnene.

Portendringen — hva den er og hva den ikke er

Hver eksponert SSH-server på internett sonderes på port 22 av automatiserte skript, døgnet rundt. Å flytte SSH-porten stopper den bakgrunnsstøyen. Det gjør deg ikke tryggere, og forskjellen betyr noe: en portskanning feier gjennom alle 65 535 portene på kort tid, så å flytte porten gjemmer deg for late skript, ikke for dem som virkelig vil inn. Å flytte porten er logghygiene. Nøklene er sikkerheten. La aldri en flyttet port bli grunnen til at kun nøkkelinnlogging «kan vente».

Med det sagt, hvis støyen plager deg, er endringen én linje:

Port 2222

Etter en omstart svarer serveren på 2222 og nekter tilkoblinger på 22 (-p forteller klienten hvilken port den skal banke på):

$ ssh -p 2222 [email protected]

ssh: connect to host localhost port 22: Connection refused

To funn fra testinga som de fleste instruksjoner om portendring hopper over. For det første gjør to Port-linjer at serveren lytter på begge portene — å legge til Port 2222 mens Port 22 står der, lukker ikke noe. Slett den gamle portlinja hvis du vil ha den lukket.

For det andre, og viktigere: på dagens Ubuntu-utgaver kjører ssh bak systemd socket-aktivering, og en tjeneste som heter ssh.socket holder port 22 åpen. Å redigere sshd_config og starte på nytt hjelper ingenting før du bytter til den vanlige tjenesten:

$ sudo systemctl disable --now ssh.socket
$ sudo systemctl enable --now ssh.service

Etterpå oppfører Port-linjene seg som dokumentert. Fedora og Arch leveres ikke med noe slikt socket-lag, og portendringen virket som beskrevet i testinga vår på begge. Flytter du porten, må klienten følge med: bruk ssh -p 2222, eller legg en Port 2222-linje under serverens oppføring i ~/.ssh/config (klientguidens kallenavn).

Les loggene dine

Hvert tilkoblingsforsøk, vellykket eller ikke, havner i journalen:

$ sudo journalctl -u ssh        # Ubuntu
$ sudo journalctl -u sshd       # Fedora

Mislykkede nøkkelforsøk ser slik ut:

Connection closed by authenticating user sshguide ::1 port 52148 [preauth]

Vellykkede omstarter annonserer seg også:

sshd[2127]: Server listening on 0.0.0.0 port 2222.

Linja om lytting er samtidig bevis på at portendringen tok effekt. Å bla gjennom denne journalen etter en uke på nett forklarer, bedre enn noen artikkel, hvorfor nøkler slår passord: volumet av gjetting mot en ekte server er konstant og enormt.

Hva denne guiden ikke dekker

En brannmur avgrenser hvilke porter som kan nås før SSH i det hele tatt blir spurt — kapittel 10 berørte landskapet, og oppsettet varierer fra distro til distro (ufw på Ubuntu, firewalld på Fedora). Automatisk blokkering av plagsomme adresser er et eget tema (fail2ban, CrowdSec), og det kan vente: når kun nøkkelinnlogging er slått på, feiler passordgjetting allerede ved døra.

Den herdede konfigurasjonen, komplett

På en server med én administrator er konfigurasjonsfila kort:

# /etc/ssh/sshd_config — the lines that matter
Port 22
PasswordAuthentication no
PermitRootLogin no
AllowUsers yourname

Valider, start på nytt og test fra en ny terminal:

$ sudo sshd -t
$ sudo systemctl restart ssh

Det er hele konfigurasjonsfila for de fleste personlige servere. Portlinja blir stående på 22 med mindre loggstøyen plager deg. Det er nøklene som beskytter.

Hvor du står nå

Serveren din svarer nå bare til navngitte brukere med nøkler, nekter kategorisk root-innlogging, og skriver ned alle som banker på. Kombinert med klientoppsettet fra SSH-guiden eier du begge endene av forbindelsen. Automatisering-kapittelet viser hvordan cron gjør vedlikehold om til planlagt arbeid, og den fullstendige sshd_config-manualen dokumenterer alle direktivene denne guiden dro over.