Modul 2 · 2.2
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:
- To nøgler virker (lektion 2.1), og du har i et nyt vindue kontrolleret, at login med en nøgle lykkes.
- 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.
- Konsollen hos din udbyder kender du: der kommer du ind uden SSH.
- 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/*.confAlle 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 yesFordi 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 yesTo 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.confmed dette indhold:
# Log kun ind med en nøgle
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-passwordHvad 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
PasswordAuthenticationstår påno. I ældre vejledninger hedder indstillingenChallengeResponseAuthentication; siden OpenSSH 8.7 er det et forældet alternativt navn for det samme. Debian sætter den allerede tilnosom 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ørstno, når du er sikker på, at login som den bruger ogsudovirker.
Valgfrit, hvis du vil mere:
AllowUsers anna
AuthenticationMethods publickeyAllowUsers 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 sshPå 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.socketGlemmer 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 sshLykkes 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_configgælder den første værdi; filer isshd_config.dlæses først. Læg dine egne indstillinger i en fil som00-beveiliging.conf. - Sæt
PasswordAuthentication noogKbdInteractiveAuthentication no; root kun med en nøgle (prohibit-password) eller slet ikke (no). - Kontrollér med
sshd -tfør genindlæsning og medsshd -T, hvilken værdi der faktisk gælder; hold øje med en50-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-reloadogsystemctl restart ssh.socket.
Quiz
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.
Læs mere
Trinene i disse artikler gælder for VPS-skærmbilledet hos WebOké; hos andre udbydere fungerer det på lignende måde.
- Sikr din VPS: de første fem minutter
- Ingen adgang til din VPS længere: hvad nu?
- Snapshots og backups af din VPS
- Vejledning til sshd_config: https://man.openbsd.org/sshd_config
- Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189
- VPS: fra første login til sikker server 3.2: Slå login med adgangskode og som root fra
