Konfigurera SSH-servern säkert

Modul 2: SSH och nycklar · Lästid: 12 minuter

Lärandemål: Efter den här lektionen kan du stänga av inloggning med lösenord och root-inloggning med lösenord, kontrollera vilken inställning som verkligen gäller och göra det utan att låsa ute dig själv.

Nyckelbegrepp: sshd, sshd_config, sshd_config.d, första värdet gäller, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, andra session, cloud-init, ssh.socket

Först skyddsnätet

I den här lektionen stänger du något som du själv måste ta dig igenom. Ett stavfel kan betyda att du inte kommer in längre. Gör därför alltid detta innan du börjar:

1. Två nycklar fungerar (lektion 2.1), och du har i ett nytt fönster kontrollerat att inloggning med nyckel fungerar.
2. En ögonblicksbild (snapshot) av din VPS. Hos WebOké skapar du den i VPS-vyn, hos andra leverantörer heter det också snapshot eller image. Om något går fel återställer du den.
3. Konsolen hos din leverantör känner du till: där kommer du in utan SSH.
4. Din nuvarande SSH-session förblir öppen ända till slutet. En pågående session fortsätter att fungera när du ändrar inställningarna eller laddar om tjänsten. Du testar varje ändring i ett andra fönster.

Var inställningarna finns

SSH-servern heter sshd. Dess inställningar finns i /etc/ssh/sshd_config. På Debian och Ubuntu står den här raden högst upp i filen:

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

Alla filer med .conf i mappen sshd_config.d läses alltså före resten av huvudfilen, i alfabetisk ordning. Det är praktiskt: du lägger dina egna inställningar i en egen fil och låter huvudfilen vara, så att en uppdatering av paketet inte påverkar dina ändringar.

Men det har en följd som överraskar många. I sshd_config gäller: för varje inställning gäller det första värdet som sshd stöter på. Senare rader med samma inställning ignoreras. Den som skriver PasswordAuthentication no längst ner i sshd_config vinner alltså inte över en fil i sshd_config.d som säger yes.

Fällan med cloud-init

Många VPS-images konfigureras vid första starten av cloud-init. Beroende på hur imagen och installationen är inställda skriver cloud-init en fil som /etc/ssh/sshd_config.d/50-cloud-init.conf med till exempel:

PasswordAuthentication yes

Eftersom den filen läses före huvudfilen är lösenordsinloggning påslagen, vad du än skriver i sshd_config. Utgå alltså inte från något, utan kontrollera:

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

Två snygga lösningar: ändra den filen till no, eller lägg dina egna inställningar i en fil som kommer tidigare i alfabetet, som 00-beveiliging.conf. En fil 99-mijn.conf fungerar just inte, för då har cloud-init redan vunnit.

Inställningarna som spelar roll

Skapa din egen fil:

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

med detta innehåll:

# Inloggning endast med nyckel
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Vad betyder varje rad?

• PasswordAuthentication no: servern accepterar inte längre lösenord. Standardvärdet i OpenSSH är yes.
• KbdInteractiveAuthentication no: "keyboard-interactive" är ett andra sätt att fråga efter ett lösenord, via PAM. Låter du den vara på kan någon ändå prova ett lösenord, även om PasswordAuthentication står på no. I äldre guider heter den här inställningen ChallengeResponseAuthentication; sedan OpenSSH 8.7 är det ett föråldrat alternativt namn för samma sak. Debian sätter den redan till no som standard, men skriv ändå in den: då är det tydligt och stämmer även på andra system.
• PermitRootLogin prohibit-password: root får logga in, men bara med nyckel. Det är standard sedan OpenSSH 7.0. Strängare är PermitRootLogin no: root får inte komma in via SSH alls, du loggar in som vanlig användare och använder sudo (lektion 3.2). Sätt no först när du är säker på att inloggning som den användaren och sudo fungerar.

Valfritt, för dig som vill gå längre:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers släpper bara in de angivna användarna; alla andra namn nekas, även om de har en giltig nyckel. Praktiskt, men glöm inte dig själv, och glöm inte att lägga till fler när du lägger till en andra administratör. AuthenticationMethods publickey säger på en rad att bara nycklar gäller.

Testa, tillämpa, kontrollera

Först låter du sshd kontrollera filen. Det startar ingenting och ändrar ingenting:

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

Ingen utdata betyder: inga fel. Vid ett stavfel ser du raden och filen. Först därefter laddar du om tjänsten:

root@web1:~# systemctl reload ssh

På Debian och Ubuntu heter tjänsten ssh, på AlmaLinux och Rocky Linux sshd.

Sedan kontrollerar du vilket värde som verkligen gäller. sshd -T visar hela den beräknade konfigurationen, med alla Include-filer inräknade:

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

(without-password är det gamla namnet på prohibit-password. Versioner av OpenSSH före 10.1, som på Debian 13 och Ubuntu 24.04, visar fortfarande det gamla namnet; nyare visar prohibit-password. Det betyder samma sak.)

Och nu det viktigaste: testa i ett andra fönster, medan det första förblir öppet.

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

Fungerar det, försök då medvetet att logga in med lösenord. Det ska misslyckas:

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 inom parentes vilka inloggningsmetoder servern fortfarande erbjuder. Står där bara publickey är allt rätt. Står även password eller keyboard-interactive där, gäller det fortfarande ett annat värde någonstans: kontrollera igen med sshd -T.

Exakt den listan kontrollerar även kursuppgiften, utifrån. Din SSH-klient frågar vid varje anslutning först vilka metoder som är tillåtna, med en förfrågan av typen "none". Servern svarar med listan, utan att något lösenord eller någon nyckel provas.

Ubuntu 24.04 och senare: ssh.socket

På Ubuntu sedan 22.10 är det inte sshd själv som lyssnar på port 22, utan systemd, via ssh.socket. Först när en anslutning kommer in startar systemd SSH-tjänsten. För inställningarna i den här lektionen spelar det ingen roll: systemctl reload ssh eller restart ssh räcker.

Det spelar däremot roll om du ändrar porten eller lyssningsadressen (Port, ListenAddress). Sedan Ubuntu 24.04 läser systemd de värdena från sshd_config, men bara efter:

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

Glömmer du det lyssnar servern helt enkelt kvar på den gamla porten. Värre: ställer du först in brandväggen på en ny port medan SSH stannar på den gamla, låser du ute dig själv. Kontrollera alltid med ss -tlnp | grep ssh var det verkligen lyssnas (lektion 5.1), och öppna den nya porten i brandväggen innan du stänger den gamla. Om en annan port är meningsfull läser du om i lektion 2.3.

Om det ändå går fel

Kommer du inte in längre öppnar du leverantörens konsol, loggar in som root (med lösenordet, för konsolen är ett "tangentbord kopplat till servern" och inte SSH) och återställer din fil:

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

Fungerar inte heller det, återställ ögonblicksbilden. Hos WebOké kan du även sätta ett nytt root-lösenord i VPS-vyn; andra leverantörer har ofta en liknande knapp eller ett räddningsläge (rescue).

På AlmaLinux och Rocky Linux

Tjänsten heter sshd (systemctl reload sshd). Även där står en Include /etc/ssh/sshd_config.d/*.conf högst upp och systemet levererar egna filer i den mappen; samma regel "första värdet gäller" gäller. Ändrar du porten måste SELinux också tillåta den porten (semanage port -a -t ssh_port_t -p tcp 2222) och firewalld öppna den.

Sammanfattning

• I sshd_config gäller det första värdet; filer i sshd_config.d läses först. Lägg dina egna inställningar i en fil som 00-beveiliging.conf.
• Sätt PasswordAuthentication no och KbdInteractiveAuthentication no; root bara med nyckel (prohibit-password) eller inte alls (no).
• Kontrollera med sshd -t före omladdningen och med sshd -T vilket värde som verkligen gäller; se upp för en 50-cloud-init.conf.
• Testa i ett andra fönster och håll den första sessionen öppen. Känn till konsolen och ta en ögonblicksbild i förväg.
• På Ubuntu 24.04+ kräver en annan port systemctl daemon-reload och systemctl restart ssh.socket.

Quiz

Uppgift

Uppgift Z2.2: Lösenordsinloggning är avstängd. Stäng av lösenordsinloggning och keyboard-interactive som i den här lektionen, och låt sedan programmet kontrollera utifrån. Fyll i IP-adressen eller värdnamnet för din server, SSH-porten (standard 22) och användarnamnet som du själv loggar in med (till exempel anna, inte root eller ett påhittat namn). Programmet loggar inte in: det frågar bara, som varje SSH-klient gör före inloggningen, vilka inloggningsmetoder din server erbjuder för den användaren. Rätt är: bara publickey.

Läs mer

Stegen i de här artiklarna gäller för VPS-vyn hos WebOké; hos andra leverantörer fungerar det på liknande sätt.

• Säkra din VPS: de första fem minuterna
• Ingen åtkomst till din VPS längre: vad gör du nu?
• Snapshots och backuper av din VPS
• Manual för 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