Gå til innholdet

Cookie-innstillinger

Velg hvilke typer cookies du tillater. Du kan når som helst endre valget via Cookie-innstillinger nederst på hver side. Personvernerklæring

Nødvendige

Alltid på

Trengs for å logge inn, beholde handlekurven og huske valgene dine. Disse er alltid på.

Hvilke cookies?
  • weboke_sessie, weboke_klant, weboke_remember: økten din og at du forblir innlogget
  • weboke_basket: handlekurven din
  • wkBtwIncl: visning av priser med eller uten mva.
  • wok_cookies: cookievalget ditt, 12 måneder

Måler hvilken annonse som fører til et besøk eller en bestilling, slik at vi ikke betaler for annonser som ikke gir noe.

Hvilke cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), opptil 90 dager
  • OpenAI Ads, annonser i ChatGPT
  • wok_aff: hvilken partner som henviste deg til oss (partnerprogram), 60 dager

4,6

Land og språk

Hvert land har sin egen nettside, med priser og mva. for det landet.

Vis

Sett opp SSH-serveren på en sikker måte

Modul 2: SSH og nøkler · Lesetid: 12 minutter

Læringsmål: Etter denne leksjonen kan du slå av innlogging med passord og root-innlogging med passord, kontrollere hvilken innstilling som faktisk gjelder, og gjøre det uten å stenge deg selv ute.

Nøkkelbegreper: sshd, sshd_config, sshd_config.d, første verdi gjelder, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, andre økt, cloud-init, ssh.socket

Først sikkerhetsnettet

I denne leksjonen stenger du noe du selv må gjennom. En skrivefeil kan bety at du ikke kommer inn lenger. Gjør derfor alltid dette før du begynner:

  1. To nøkler fungerer (leksjon 2.1), og du har kontrollert i et nytt vindu at innlogging med nøkkel virker.
  2. Et øyeblikksbilde (snapshot) av VPS-en din. Hos WebOké lager du det i VPS-skjermbildet. Hos andre leverandører heter det også snapshot eller image. Går noe galt, gjenoppretter du det.
  3. Konsollen hos leverandøren din kjenner du: der kommer du inn uten SSH.
  4. Den nåværende SSH-økten din forblir åpen helt til slutt. En pågående økt fortsetter å virke når du endrer innstillingene eller laster tjenesten på nytt. Du tester hver endring i et andre vindu.

Hvor innstillingene ligger

SSH-serveren heter sshd. Innstillingene ligger i /etc/ssh/sshd_config. På Debian og Ubuntu står denne linjen øverst i filen:

Include /etc/ssh/sshd_config.d/*.conf

Alle filer med .conf i mappen sshd_config.d leses altså før resten av hovedfilen, i alfabetisk rekkefølge. Det er praktisk: du legger dine egne innstillinger i en egen fil og lar hovedfilen være i fred, slik at en oppdatering av pakken ikke rører endringene dine.

Men det har en følge som overrasker mange. I sshd_config gjelder dette: for hver innstilling er det den første verdien sshd finner som gjelder. Senere linjer med samme innstilling ignoreres. Setter du PasswordAuthentication no nederst i sshd_config, vinner du altså ikke over en fil i sshd_config.d som sier yes.

Fellen med cloud-init

Mange VPS-images settes opp ved første oppstart av cloud-init. Avhengig av hvordan imaget og installasjonen er satt opp, skriver cloud-init en fil som /etc/ssh/sshd_config.d/50-cloud-init.conf med for eksempel dette innholdet:

PasswordAuthentication yes

Fordi den filen leses før hovedfilen, er passordinnlogging slått på, uansett hva du skriver i sshd_config. Ikke ta det for gitt, men sjekk:

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

To ryddige løsninger: endre den filen til no, eller legg dine egne innstillinger i en fil som kommer tidligere i alfabetet, som 00-beveiliging.conf. En fil 99-mijn.conf virker derimot ikke, for da har cloud-init allerede vunnet.

Innstillingene som betyr noe

Lag din egen fil:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

med dette innholdet:

# Innlogging kun med nøkkel
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Hva betyr hver linje?

  • PasswordAuthentication no: serveren godtar ikke lenger passord. Standardverdien i OpenSSH er yes.
  • KbdInteractiveAuthentication no: "keyboard-interactive" er en annen måte å be om passord på, via PAM. Lar du denne stå på, kan noen likevel prøve et passord, selv om PasswordAuthentication står på no. I eldre veiledninger heter denne innstillingen ChallengeResponseAuthentication. Siden OpenSSH 8.7 er det et utdatert alternativt navn for det samme. Debian setter den allerede til no som standard, men skriv den inn likevel: da er det tydelig, og det stemmer også på andre systemer.
  • PermitRootLogin prohibit-password: root får logge inn, men bare med nøkkel. Det har vært standard siden OpenSSH 7.0. Strengere er PermitRootLogin no: root kommer ikke inn via SSH i det hele tatt, du logger inn som vanlig bruker og bruker sudo (leksjon 3.2). Sett no først når du er sikker på at innlogging som den brukeren og sudo fungerer.

Valgfritt, for deg som vil gå lenger:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers slipper bare inn brukerne som er oppført. Alle andre navn avvises, også om de har en gyldig nøkkel. Praktisk, men ikke glem deg selv, og ikke glem å utvide listen når du legger til en ny administrator. AuthenticationMethods publickey sier på én linje at bare nøkler gjelder.

Test, ta i bruk, kontroller

Først lar du sshd kontrollere filen. Dette starter ingenting og endrer ingenting:

root@web1:~# sshd -t
root@web1:~#

Ingen utdata betyr: ingen feil. Ved en skrivefeil ser du linjen og filen. Først da laster du tjenesten på nytt:

root@web1:~# systemctl reload ssh

På Debian og Ubuntu heter tjenesten ssh, på AlmaLinux og Rocky Linux sshd.

Deretter kontrollerer du hvilken verdi som faktisk gjelder. sshd -T viser hele den ferdig beregnede konfigurasjonen, med alle Include-filer tatt med:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password er det gamle navnet på prohibit-password. Versjoner av OpenSSH før 10.1, som på Debian 13 og Ubuntu 24.04, viser fortsatt det gamle navnet. Nyere versjoner viser prohibit-password. Det betyr det samme.)

Og nå det viktigste: test i et andre vindu, mens det første forblir åpent.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Virker det, prøver du bevisst å logge inn med passord. Dette skal mislykkes:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

Etter Permission denied står det i parentes hvilke innloggingsmetoder serveren fortsatt tilbyr. Står det bare publickey, er alt i orden. Står det også password eller keyboard-interactive, gjelder det fortsatt en annen verdi et sted: sjekk igjen med sshd -T.

Akkurat den listen kontrollerer også kursoppgaven, utenfra. SSH-klienten din spør ved hver tilkobling først hvilke metoder som er tillatt, med en forespørsel av typen "none". Serveren svarer med listen, uten at noe passord eller noen nøkkel blir prøvd.

Ubuntu 24.04 og nyere: ssh.socket

På Ubuntu siden 22.10 er det ikke sshd selv som lytter på port 22, men systemd, via ssh.socket. Først når en tilkobling kommer inn, starter systemd SSH-tjenesten. For innstillingene i denne leksjonen spiller det ingen rolle: systemctl reload ssh eller restart ssh er nok.

Det spiller derimot en rolle når du endrer porten eller lytteadressen (Port, ListenAddress). Siden Ubuntu 24.04 leser systemd disse verdiene fra sshd_config, men bare etter:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Glemmer du det, lytter serveren fortsatt på den gamle porten. Verre: setter du først brannmuren til en ny port mens SSH blir værende på den gamle, stenger du deg selv ute. Kontroller alltid med ss -tlnp | grep ssh hvor det faktisk lyttes (leksjon 5.1), og åpne den nye porten i brannmuren før du stenger den gamle. Om en annen port er fornuftig, leser du i leksjon 2.3.

Hvis det likevel går galt

Kommer du ikke inn lenger, åpner du konsollen hos leverandøren din, logger inn som root (med passordet, for konsollen er et "tastatur koblet til serveren" og ikke SSH) og ruller tilbake filen din:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Virker ikke det heller, gjenoppretter du øyeblikksbildet. Hos WebOké kan du også sette et nytt root-passord i VPS-skjermbildet. Andre leverandører har ofte en tilsvarende knapp eller en redningsmodus (rescue).

På AlmaLinux og Rocky Linux

Tjenesten heter sshd (systemctl reload sshd). Også der står det en Include /etc/ssh/sshd_config.d/*.conf øverst, og systemet leverer egne filer i den mappen. Den samme regelen "første verdi gjelder" gjelder. Endrer du porten, må SELinux også tillate den porten (semanage port -a -t ssh_port_t -p tcp 2222), og firewalld må åpne den.

Oppsummering

  • I sshd_config gjelder den første verdien. Filer i sshd_config.d leses først. Legg dine egne innstillinger i en fil som 00-beveiliging.conf.
  • Sett PasswordAuthentication no og KbdInteractiveAuthentication no. Root bare med nøkkel (prohibit-password) eller ikke i det hele tatt (no).
  • Kontroller med sshd -t før du laster på nytt, og med sshd -T hvilken verdi som faktisk gjelder. Se opp for en 50-cloud-init.conf.
  • Test i et andre vindu og hold den første økten åpen. Kjenn konsollen og lag et øyeblikksbilde på forhånd.
  • På Ubuntu 24.04+ krever en annen port systemctl daemon-reload og systemctl restart ssh.socket.

Quiz

1. Nederst i /etc/ssh/sshd_config står PasswordAuthentication no, men du kan fortsatt logge inn med passord. Hva er den mest sannsynlige årsaken?



2. Hvorfor setter du KbdInteractiveAuthentication no i tillegg til PasswordAuthentication no?



3. Hva betyr PermitRootLogin prohibit-password?



4. I hvilken rekkefølge jobber du tryggest?



5. På Ubuntu 24.04 endrer du linjen Port 22 til Port 2222 og kjører systemctl restart ssh. Med ss -tlnp ser du at det fortsatt lyttes på 22. Hva har du glemt?



Oppgave

Oppgave Z2.2: Passordinnlogging er slått av. Slå av passordinnlogging og keyboard-interactive slik det er vist i denne leksjonen, og la deretter programmet sjekke utenfra. Fyll inn IP-adressen eller vertsnavnet til serveren din, SSH-porten (standard 22) og brukernavnet du selv logger inn med (for eksempel anna, ikke root eller et oppdiktet navn). Programmet logger ikke inn: det spør bare, slik enhver SSH-klient gjør før innlogging, hvilke innloggingsmetoder serveren din tilbyr for den brukeren. Riktig svar er: bare publickey.

Oppgave Z2.2: Passordinnlogging er slått av

Vi logger ikke inn og prøver ikke noe passord eller nøkkel. Først viser du at serveren er din: klikk på "Vis koden min" og legg en fil /.well-known/weboke-cursus-<code>.txt med bare den koden på webserveren til vertsnavnet ditt. Vi henter den direkte fra hver IP-adresse vi kontrollerer (IPv4 og IPv6 hver for seg); en TXT-post teller ikke her. Kontrollen kommer fra heavy.webawere.nl (185.158.167.16 og 2a07:ae80:100:0:185:158:167:16), ikke fra webserveren vår. Bare for påmeldte kursdeltakere; maks 6 kontroller per time per server. Vi spør bare hvilke innloggingsmetoder serveren din tilbyr for brukernavnet ditt, slik alle SSH-klienter gjør før innlogging. Fyll inn din egen bruker: et ukjent navn havner som "Invalid user" i loggen din og teller som ett forsøk hos fail2ban.





Det du fyller inn, og det vi finner, lagrer vi ikke. Nettleseren din husker svarene dine og om du har bestått oppgaven. Er du logget inn, lagrer vi kun at du har (nesten) bestått oppgaven i Mine kurs; der kan du også slette det.

Les mer

Stegene i disse artiklene gjelder for VPS-skjermbildet hos WebOké. Hos andre leverandører fungerer det på lignende måte.

Et øyeblikk …

Sett opp domenene dine

Ordne for hvert domene navnetjenerne, koblingen til hostingen din og hvem som blir innehaver.

Laster inn domenene dine…