Gå direkte til indholdet

Cookieindstillinger

Vælg for hver type, hvilke cookies du tillader. Du kan altid ændre dit valg via Cookieindstillinger nederst på hver side. Privatlivspolitik

Nødvendige

Altid slået til

Nødvendige for at logge ind, gemme din kurv og huske dine valg. De er altid slået til.

Hvilke cookies?
  • weboke_sessie, weboke_klant, weboke_remember: din session og at forblive logget ind
  • weboke_basket: din kurv
  • wkBtwIncl: vise priser med eller uden moms
  • wok_cookies: dit cookievalg, 12 måneder

Måler, hvilken annonce der fører til et besøg eller en bestilling, så vi ikke betaler for annoncer, der ikke virker.

Hvilke cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), op til 90 dage
  • OpenAI Ads, annoncer i ChatGPT
  • wok_aff: hvilken partner der henviste dig til os (affiliateprogram), 60 dage

4,6

Land og sprog

Hvert land har sin egen side med landets priser og moms.

Se

Sæt SSH-serveren sikkert op

Modul 2: SSH og nøgler · Læsetid: 12 minutter

Læringsmål: Efter denne lektion kan du slå login med adgangskode og root-login med adgangskode fra, kontrollere hvilken indstilling der faktisk gælder, og gøre det uden at låse dig selv ude.

Centrale begreber: sshd, sshd_config, sshd_config.d, første værdi gælder, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, anden session, cloud-init, ssh.socket

Først sikkerhedsnettet

I denne lektion lukker du en dør, som du selv skal igennem. En tastefejl kan betyde, at du ikke længere kan komme ind. Gør derfor altid dette, før du går i gang:

  1. To nøgler virker (lektion 2.1), og du har i et nyt vindue kontrolleret, at login med en nøgle lykkes.
  2. Et snapshot af din VPS. Hos WebOké laver du det i VPS-skærmbilledet, hos andre udbydere hedder det også snapshot eller image. Går det galt, gendanner du det.
  3. Konsollen hos din udbyder kender du: der kommer du ind uden SSH.
  4. Din nuværende SSH-session forbliver åben til det sidste. En igangværende session bliver ved med at virke, når du ændrer indstillingerne eller genindlæser tjenesten. Du tester hver ændring i et andet vindue.

Hvor indstillingerne ligger

SSH-serveren hedder sshd. Dens indstillinger ligger i /etc/ssh/sshd_config. På Debian og Ubuntu står denne linje øverst i filen:

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

Alle filer med .conf i mappen sshd_config.d bliver altså læst før resten af hovedfilen, i alfabetisk rækkefølge. Det er praktisk: du lægger dine egne indstillinger i en egen fil og lader hovedfilen være, så en opdatering af pakken ikke rører dine ændringer.

Men det har en konsekvens, som overrasker mange. I sshd_config gælder: for hver indstilling tæller den første værdi, sshd møder. Senere linjer med samme indstilling ignoreres. Skriver du PasswordAuthentication no nederst i sshd_config, vinder du altså ikke over en fil i sshd_config.d, der siger yes.

Faldgruben med cloud-init

Mange VPS-images bliver sat op af cloud-init ved første start. Afhængigt af hvordan imaget og installationen er sat op, skriver cloud-init en fil som /etc/ssh/sshd_config.d/50-cloud-init.conf med for eksempel:

PasswordAuthentication yes

Fordi den fil læses før hovedfilen, er login med adgangskode slået til, uanset hvad du skriver i sshd_config. Gå derfor ikke ud fra noget, men kig efter:

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 pæne løsninger: ret den fil til no, eller læg dine egne indstillinger i en fil, der kommer tidligere i alfabetet, som 00-beveiliging.conf. En fil 99-mijn.conf virker netop ikke, for så har cloud-init allerede vundet.

De indstillinger, der betyder noget

Opret din egen fil:

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

med dette indhold:

# Log kun ind med en nøgle
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Hvad betyder hver linje?

  • PasswordAuthentication no: serveren accepterer ikke længere en adgangskode. Standardværdien i OpenSSH er yes.
  • KbdInteractiveAuthentication no: "keyboard-interactive" er en anden måde at bede om en adgangskode på, via PAM. Lader du den være slået til, kan nogen stadig prøve en adgangskode, også selvom PasswordAuthentication står på no. I ældre vejledninger hedder indstillingen ChallengeResponseAuthentication; siden OpenSSH 8.7 er det et forældet alternativt navn for det samme. Debian sætter den allerede til no som standard, men skriv den alligevel: så er det tydeligt, og det passer også på andre systemer.
  • PermitRootLogin prohibit-password: root må logge ind, men kun med en nøgle. Det er standarden siden OpenSSH 7.0. Strengere er PermitRootLogin no: root må slet ikke komme ind via SSH, du logger ind som almindelig bruger og bruger sudo (lektion 3.2). Sæt først no, når du er sikker på, at login som den bruger og sudo virker.

Valgfrit, hvis du vil mere:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers lukker kun de nævnte brugere ind; alle andre navne afvises, også hvis de har en gyldig nøgle. Praktisk, men glem ikke dig selv, og glem ikke at tilføje en anden administrator, når du får en. AuthenticationMethods publickey siger på én linje, at kun nøgler gælder.

Test, anvend, kontrollér

Først lader du sshd kontrollere filen. Det starter ikke noget og ændrer ikke noget:

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

Intet output betyder: ingen fejl. Ved en tastefejl ser du linjen og filen. Først derefter genindlæser du tjenesten:

root@web1:~# systemctl reload ssh

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

Derefter kontrollerer du, hvilken værdi der faktisk gælder. sshd -T viser den fulde, beregnede konfiguration med alle Include-filer behandlet:

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

(without-password er det gamle navn for prohibit-password. Versioner af OpenSSH før 10.1, som på Debian 13 og Ubuntu 24.04, viser stadig det gamle navn; nyere viser prohibit-password. Det betyder det samme.)

Og nu det vigtigste: test i et andet vindue, mens det første forbliver åbent.

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

Virker det, så prøv bevidst at logge ind med en adgangskode. Det skal mislykkes:

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

Efter Permission denied står der i parentes, hvilke loginmetoder serveren stadig tilbyder. Står der kun publickey, er det i orden. Står der også password eller keyboard-interactive, gælder der et sted stadig en anden værdi: kig igen med sshd -T.

Netop den liste kontrollerer kursusopgaven også, udefra. Din SSH-klient spørger ved hver forbindelse først, hvilke metoder der er tilladt, med en forespørgsel af typen "none". Serveren svarer med listen, uden at der bliver prøvet en adgangskode eller nøgle.

Ubuntu 24.04 og senere: ssh.socket

På Ubuntu siden 22.10 er det ikke sshd selv, der lytter på port 22, men systemd via ssh.socket. Først når der kommer en forbindelse ind, starter systemd SSH-tjenesten. For indstillingerne i denne lektion gør det ingen forskel: systemctl reload ssh eller restart ssh er nok.

Det gør derimod en forskel, når du ændrer porten eller lytteadressen (Port, ListenAddress). Siden Ubuntu 24.04 læser systemd de værdier fra sshd_config, men kun efter:

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

Glemmer du det, lytter serveren stadig på den gamle port. Værre: sætter du først din firewall op til en ny port, mens SSH bliver på den gamle, så låser du dig selv ude. Kontrollér altid med ss -tlnp | grep ssh, hvor der faktisk lyttes (lektion 5.1), og åbn den nye port i din firewall, før du lukker den gamle. Om en anden port giver mening, kan du læse i lektion 2.3.

Hvis det alligevel går galt

Kan du ikke længere komme ind, åbner du konsollen hos din udbyder, logger ind som root (med adgangskoden, for konsollen er et "tastatur på serveren" og ikke SSH) og ruller din fil tilbage:

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

Lykkes det heller ikke, så gendan dit snapshot. Hos WebOké kan du også sætte en ny root-adgangskode i VPS-skærmbilledet; andre udbydere har ofte en lignende knap eller en redningstilstand (rescue).

På AlmaLinux og Rocky Linux

Tjenesten hedder sshd (systemctl reload sshd). Også der står en Include /etc/ssh/sshd_config.d/*.conf øverst, og systemet leverer egne filer i den mappe; samme regel om at "første værdi gælder" gælder. Ændrer du porten, skal SELinux også tillade den port (semanage port -a -t ssh_port_t -p tcp 2222), og firewalld skal åbne den.

Opsummering

  • I sshd_config gælder den første værdi; filer i sshd_config.d læses først. Læg dine egne indstillinger i en fil som 00-beveiliging.conf.
  • Sæt PasswordAuthentication no og KbdInteractiveAuthentication no; root kun med en nøgle (prohibit-password) eller slet ikke (no).
  • Kontrollér med sshd -t før genindlæsning og med sshd -T, hvilken værdi der faktisk gælder; hold øje med en 50-cloud-init.conf.
  • Test i et andet vindue, og hold den første session åben. Kend konsollen, og tag et snapshot på forhånd.
  • På Ubuntu 24.04+ kræver en anden port systemctl daemon-reload og systemctl restart ssh.socket.

Quiz

1. Nederst i /etc/ssh/sshd_config står PasswordAuthentication no, men du kan stadig logge ind med en adgangskode. Hvad er den mest sandsynlige årsag?



2. Hvorfor sætter du ud over PasswordAuthentication no også KbdInteractiveAuthentication no?



3. Hvad betyder PermitRootLogin prohibit-password?



4. I hvilken rækkefølge arbejder du mest sikkert?



5. På Ubuntu 24.04 ændrer du linjen Port 22 til Port 2222 og kører systemctl restart ssh. Med ss -tlnp ser du, at der stadig lyttes på 22. Hvad har du glemt?



Opgave

Opgave Z2.2: Login med adgangskode er slået fra. Slå login med adgangskode og keyboard-interactive fra som i denne lektion, og lad derefter programmet kigge udefra. Udfyld IP-adressen eller værtsnavnet på din server, SSH-porten (standard 22) og det brugernavn, du selv logger ind med (for eksempel anna, ikke root eller et opdigtet navn). Programmet logger ikke ind: det spørger kun, som enhver SSH-klient gør før login, hvilke loginmetoder din server tilbyder for den bruger. Korrekt er: kun publickey.

Opgave Z2.2: Login med adgangskode er slået fra

Vi logger ikke ind og prøver hverken adgangskode eller nøgle. Først viser du, at serveren er din: klik på "Vis min kode", og læg en fil /.well-known/weboke-cursus-<code>.txt med kun den kode på webserveren for dit værtsnavn. Vi henter den direkte fra hver IP-adresse, vi kontrollerer (IPv4 og IPv6 hver for sig); en TXT-record tæller ikke her. Kontrollen kommer fra heavy.webawere.nl (185.158.167.16 og 2a07:ae80:100:0:185:158:167:16), ikke fra vores webserver. Kun for tilmeldte kursister; højst 6 kontroller i timen pr. server. Vi spørger kun, hvilke loginmetoder din server tilbyder for dit brugernavn, sådan som enhver SSH-klient gør før login. Udfyld din egen bruger: et ukendt navn havner som "Invalid user" i din log og tæller som ét forsøg i fail2ban.





Det, du udfylder, og hvad vi finder, gemmer vi ikke. Din browser husker dine svar, og om du har bestået opgaven. Er du logget ind, gemmer vi kun, at du (næsten) bestod opgaven, i Mine kurser; der kan du også slette det.

Læs mere

Trinene i disse artikler gælder for VPS-skærmbilledet hos WebOké; hos andre udbydere fungerer det på lignende måde.

Et øjeblik…

Opsæt dine domæner

Angiv for hvert domæne navneserverne, tilknytningen til din hosting, og hvem der bliver ejer.

Indlæser dine domæner…