📬 En uppföljare till "Linux — grunderna alla borde kunna"
Nästa steg efter grunderna

I förra inlägget gick vi igenom filsystem, rättigheter, systemd, pakethantering och nätverk. Nu tar vi nästa naturliga steg: hur du faktiskt kommer åt en Linux-maskin som står någon annanstans — säkert.

Så fort du har mer än en Linux-maskin slutar du sitta framför den. Servern i homelabbet, molninstansen, routern — allt sköts på distans via SSH (Secure Shell). Det är en krypterad anslutning som ger dig en terminal på en annan dator, oavsett var den fysiskt befinner sig.

Problemet är att de flesta börjar med lösenordsinloggning över SSH — och det är precis det en angripare hoppas att du gör. Lösenord kan gissas, brute-forceras och läcka. Nyckelbaserad autentisering löser det, och tar bara några minuter att sätta upp.

Testa direkt: din första SSH-anslutning
Öppna en terminal och prova

Så länge SSH-servern (openssh-server) är installerad och igång på maskinen du vill nå, kopplar du upp dig så här:

Anslut till en server
$ ssh adam@192.168.1.50 # användarnamn@ip-adress eller hostname adam@192.168.1.50's password: # lösenordsinloggning — det vi ska byta ut
💡 Standardporten för SSH är 22. Vill du ansluta på en annan port: ssh -p 2222 adam@192.168.1.50.
Från lösenord till nyckel
Fyra steg till säkrare inloggning
01 — Generera ett nyckelpar

Ett SSH-nyckelpar består av en privat nyckel (stannar på din dator, delas aldrig) och en publik nyckel (läggs på servern du vill logga in på). De hör alltid ihop.

$ ssh-keygen -t ed25519 -C "adam@laptop" # skapar nyckelparet Enter file in which to save the key (/home/adam/.ssh/id_ed25519): Enter passphrase (empty for no passphrase):
💡 ed25519 är en modern, snabb och säker nyckeltyp — använd den istället för äldre rsa-nycklar om du inte har ett specifikt skäl att inte göra det. Ett lösenfras (passphrase) på nyckeln är ett extra skyddslager om den privata nyckeln skulle läcka.

02 — Kopiera den publika nyckeln till servern

Verktyget ssh-copy-id gör precis det som namnet säger — kopierar din publika nyckel till serverns lista över godkända nycklar.

$ ssh-copy-id adam@192.168.1.50 # sista gången du behöver ange lösenordet
03 — Testa nyckelinloggningen

Anslut igen — den här gången utan att ange något lösenord:

$ ssh adam@192.168.1.50 # loggar in direkt med nyckeln
04 — Stäng av lösenordsinloggning helt

Först när nyckelinloggningen är bekräftat fungerande stänger du av möjligheten att logga in med lösenord över SSH, i konfigurationsfilen på servern:

$ sudo nano /etc/ssh/sshd_config PasswordAuthentication no # tillåt bara nyckelbaserad inloggning PermitRootLogin no # tillåt aldrig root att logga in direkt $ sudo systemctl restart ssh # ladda om konfigurationen
⚠️ Testa alltid nyckelinloggningen i ett separat terminalfönster innan du stänger av lösenord och startar om tjänsten. Om något är fel och du bara har en anslutning öppen riskerar du att låsa dig ute helt.
"Ett lösenord är något du kommer ihåg. En nyckel är något du har. Kombinationen av de två är svår att knäcka — men bara nyckeln är redan bra mycket bättre än bara lösenordet."
Vad händer egentligen när du loggar in med nyckel?
Asymmetrisk kryptering i praktiken

Det känns nästan magiskt att en fil på din dator kan bevisa vem du är utan att någonting hemligt någonsin skickas över nätverket. Så här går det till:

1. Din publika nyckel ligger sedan tidigare i en fil på servern: ~/.ssh/authorized_keys. Den är inte hemlig — det spelar ingen roll om någon annan ser den.

2. När du ansluter skickar servern en slumpmässig utmaning, krypterad med din publika nyckel.

3. Bara din privata nyckel kan låsa upp den utmaningen. Din dator gör det lokalt och skickar tillbaka svaret.

4. Servern verifierar svaret mot den publika nyckeln den redan har. Stämmer det — du är inloggad. Din privata nyckel har aldrig lämnat din dator.

💡 Det är därför den publika nyckeln (filen som slutar på .pub) är helt ofarlig att dela eller ladda upp — det är bara den privata nyckeln (utan .pub) som måste skyddas.
Vilken nyckeltyp ska man egentligen välja?
ed25519, rsa och ecdsa

ed25519 — modern standard sedan några år tillbaka. Kortare nycklar, snabbare beräkningar och minst lika säker (om inte säkrare) som alternativen nedan. Standardvalet om inget annat säger emot.

rsa — den gamla standarden, fortfarande vanlig och väl stödd av äldre system. Kräver längre nycklar (minst 3072 bitar, gärna 4096) för motsvarande säkerhet som ed25519.

ecdsa — sällan förstahandsvalet idag. Fungerar, men ed25519 föredras generellt av säkerhetsskäl kring hur nycklarna genereras.

⚠️ Vissa äldre enheter — gamla routrar, switchar, viss inbäddad hårdvara — stöder ännu inte ed25519. Stöter du på det är rsa med minst 4096 bitar ett rimligt alternativ: ssh-keygen -t rsa -b 4096.
Slippa skriva lösenfrasen varje gång
ssh-agent

Satte du en lösenfras på nyckeln (rekommenderat) blir det snabbt tjatigt att skriva den vid varje anslutning. ssh-agent håller nyckeln upplåst i minnet under din session, så du bara anger frasen en gång:

$ eval "$(ssh-agent -s)" # starta agenten för sessionen $ ssh-add ~/.ssh/id_ed25519 # lås upp nyckeln en gång, håll den i minnet

De flesta skrivbordsmiljöer (GNOME, KDE) startar en agent automatiskt vid inloggning, så i praktiken behöver du sällan tänka på det.

En server exponerad mot internet? Härda den ytterligare
Tre steg utöver nyckelinloggning
Byt bort standardporten

Port 22 är den första en angripare provar. Att byta port stoppar ingen riktad attack, men eliminerar nästan all automatiserad skräpskanning som ständigt bankar på nätet:

Port 2222 # i /etc/ssh/sshd_config, valfri ledig port över 1024
Installera fail2ban

fail2ban övervakar loggarna och blockerar automatiskt IP-adresser som gör upprepade misslyckade inloggningsförsök — oavsett om det är brute-force mot ett lösenord eller bara skräptrafik:

$ sudo apt install fail2ban # installera $ sudo systemctl enable --now fail2ban # starta direkt och vid uppstart
Begränsa vilka som får ansluta

Har du bara en handfull användare som faktiskt ska kunna nå servern över SSH, begränsa det explicit i konfigurationen:

AllowUsers adam # bara denna användare får logga in via SSH
💡 Kombinationen nyckelinloggning + bytt port + fail2ban täcker in de allra flesta automatiserade attacker mot en exponerad SSH-tjänst.
När det inte fungerar
Felsökning med -v

Fastnar anslutningen, eller frågar den om lösenord trots att du satt upp en nyckel? Lägg till -v (eller -vvv för maximal detaljnivå) för att se exakt vad som händer:

$ ssh -v adam@192.168.1.50 # visar varje steg i anslutningsprocessen

De vanligaste orsakerna till att en nyckel inte accepteras: fel rättigheter på ~/.ssh (ska vara 700) eller på authorized_keys (ska vara 600) — SSH vägrar helt enkelt lita på en nyckelfil som andra användare kan skriva till.

$ chmod 700 ~/.ssh # bara ägaren får komma åt mappen $ chmod 600 ~/.ssh/authorized_keys # bara ägaren får läsa/skriva filen
En smidigare vardag med SSH-config
Sluta komma ihåg IP-adresser

Har du flera servrar blir det snabbt jobbigt att hålla reda på IP-adresser, användarnamn och portar. Lösningen är en config-fil på din egen dator:

$ nano ~/.ssh/config Host homelab HostName 192.168.1.50 User adam Port 22 IdentityFile ~/.ssh/id_ed25519

Efter det räcker det med ssh homelab — SSH fyller i resten åt dig.

Bonus: flytta filer med samma nyckel
scp och rsync

Samma nyckel och samma anslutning kan användas för att flytta filer, inte bara för att öppna en terminal:

$ scp rapport.txt adam@homelab:/home/adam/ # kopiera en fil till servern $ rsync -avz ./mapp/ adam@homelab:/home/adam/mapp/ # synka en hel mapp effektivare
💡 rsync kopierar bara det som faktiskt ändrats, vilket gör det betydligt snabbare än scp för stora mappar eller återkommande synkroniseringar.

// Sammanfattning — SSH

  • SSH ger dig en krypterad terminal till en annan dator, oavsett var den befinner sig fysiskt
  • Ett nyckelpar består av en privat nyckel (stannar hos dig) och en publik nyckel (läggs på servern)
  • ssh-keygen skapar nyckelparet, ssh-copy-id kopierar den publika nyckeln till servern
  • Stäng av PasswordAuthentication och PermitRootLogin i sshd_config — men först efter att nyckeln testats
  • Din privata nyckel lämnar aldrig din dator — det är den publika nyckeln som ligger på servern
  • ed25519 är standardvalet idag, rsa (minst 4096 bitar) fungerar som reservalternativ på äldre system
  • ssh-agent gör att du slipper skriva nyckelns lösenfras vid varje anslutning
  • Exponerad server? Byt port, installera fail2ban och begränsa vilka användare som får ansluta
  • En ~/.ssh/config-fil gör att du slipper komma ihåg IP-adresser och användarnamn
  • Samma nyckel används av scp och rsync för att flytta filer säkert

Nyckelbaserad SSH-inloggning är en av de förbättringar som ger mest säkerhet för minst ansträngning i hela IT-världen. Femton minuters jobb, och du har stängt en av de vanligaste vägarna in som angripare faktiskt använder mot exponerade servrar.