Wallmander.net

För de som använder Linux- och/eller Unix-baserat operativsystem och som använder terminalen vet de flesta om att SSH är guld värt när det kommer till att styra system på distans. Ett terminal-liv utan SSH skulle nog inte vara det samma, speciellt om man satt på en osäker Telnet anslutning eller VNC på en internetanslutning men en hastighet som kan matcha ett gammalt telefonmodemen.

Att installera en SSH-server är som bekant mycket enkelt, allt man behöver göra är att skriva följande kommando i Ubuntu eller andra Debian-baserade system:

sudo apt-get install openssh-server

Sitter man på Mac kan man aktivera ssh-servern genom att gå in under Systeminställningar -> Delning och bocka i ”Fjärrinlogging”.

Även om standardinstallationen är okej grundkonfiguration så behöver man göra en del tweeks för att säkra upp den.

Innan du börjar…

Var försiktig med vad för inställningar du ställer in på din SSH-server. I värsta fall kan du stänga ute dig själv från serven, men så länge som du kan komma åt och ändra SSH-konfigurationen och har möjlighet att starta om SSH-serven på något annat sätt än via SSH ska detta inte vara några problem.

Nedan kommer jag att referera till ”konfigurationsfilen” eller ”ssh-konfigurationen”, med det menar jag att öppna filen /etc/ssh/sshd_config. Lättast att göra detta är med hjälp av följande kommando:

sudo nano /etc/ssh/sshd_config

Något annat som är viktigt är att oavsett om man följer denna guide i sin helhet eller delar, är det viktigt att efter du har gjort dina inställningar att du startar om SSH-serven. Detta är för att nya inställningar börjar inte gälla först när SSH-serven har startas om. Smidigaste sättet att starta om SSH-serven är med följande kommando:

sudo service ssh restart

Att starta om hela serven/datorn är också ett alternativ.

1. Tillåt ej root-inloggingar

SSH-server som tillåter root-inloggingar med lösenord utgör en stor säkerhetsrisk och bör aldrig tillåtas. Detta kan fixas mycket enkelt genom att ha följande konfiguration /etc/ssh/sshd_config:

PermitRootLogin no

Behöver man root-access, logga in som en vanlig användare och använd istället sudo eller växla till root-användaren med kommandot:

su -

Vill man ändå logga in direkt på root-användaren, ej att rekommendera, så skulle man kunna begräna till att enbart tillåta SSH-nycklar:

PermitRootLogin without-password

2. Skydda mot brute-force attacker

Enklast är att skydda sig mot denna typ av attacker är att installera verktyg så som fail2ban. Vad den gör är att om man misslyckas med SSH-inloggingen för många gånger på kort tid blir man temporärt spärrad från servern. Beroende på inställningar så varar denna spärr mellan 5-15 minuter innan man kan försöka igen.

För att installera fail2ban, kör följande:

sudo apt-get install fail2ban

För att förhindra att man blir själv utestängd kan man lägga in sitt egna IP-nummer med inställningen ”ignoreip” som hittas i filen /etc/fail2ban/jail.conf.

Har man inte möjligheten att installera ett verktyg så som fail2ban är det bästa alternativet att byta från port 22 till någon annan port så som 2222. Dock hindrar det i princip bara från automatiska bottar som försöker komma in på SSH-servrar som har dåliga lösenord.

3. Begränsa behörigheten

Är det verkligen nödvändigt att alla användare på en server ska ha tillgång till SSH? Ibland skapas det konton på en server som bara till för att köra ett visst program (t.ex. Plex), och det är onödigt att dessa användare får SSH-behörighet. Därför kan det vara bra att begränsa vilka användare som får använda sig av SSH alternativt vilka som inte får använda SSH. Att åstadkomma detta är rätt lätt, då man kan styra detta via ssh-konfigurationen.

Leta bara upp efter följande:

#AllowUsers

Och ändra det till:

AllowUsers

Om du inte hittar denna inställning lägger du istället in ”AllowUsers” på en ny rad längst ned i filen.

Vad AllowUsers gör är, som namnet antyder, enbart tillåter de användare som är definierade av denna inställning. Alla andra användare betraktas som obehöriga och kan därmed överhuvudtaget inte logga in via SSH. Varje användare som läggs in avskiljes med ett mellanrum. I slutändan ska det se ut ungefär så här:

AllowUsers user1 user2 user3

Det finns även en syskon-inställning vid namn DenyUsers, som ser och fungerar precis som AllowUsers, med undantaget att den istället förbjuder de användare som är angivna från att komma åt SSH. Alla andra användare betraktas som behöriga och kan utan hinder logga in via SSH.

4. Glöm lösenorden, använd SSH-nycklar!

Är du trött på att använda lösenord och samtidigt som du höjer säkerheten? Vill du göra det möjligt för automatiska script loggar in på servrarna? Lösningen är att börja använda SSH-nycklar.

Innan vi börjar generera nycklar på arbetsdatorn ska vi se till konfigurationen på serverdatorn. För att man ska kunna koppla upp dig mot serven med SSH-nyckel krävs följande inställningar i konfigurationsfilen:

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

När du har kontrollerat att det är rätt inställningar är det sedan dags att generera SSH-nycklar på arbetsdatorn. Eftersom att denna guide är inriktad mot Linux-plattformen för både arbetsdator och server kommer jag enbart ta upp hur man genererar nycklar på en Linux-burk. Men råkar du ha Windows på din arbetsdator finns Putty att tillgå som gör uppkopplingarna smidiga. Vill man använda sig av SSH-nycklar och generera dessa på en Windowsdator kan läsa denna guide.

Att skapa SSH-nycklar i linux och OS X är mycket enkelt, allt man behöver göra är att skriva följande i en terminal på din arbetsdator:

ssh-keygen -o -a 100 -t ed25519 -C användare@dator

Vid frågan ”Enter passphrase” rekommenderas att man har ett lösenord. Skulle nyckeln komma på villovägar så köper man sig tid till dess att man har tagit bort nyckeln och genererat en ny.

När denna har körts så skapas det två filer i ~/.ssh/ katalogen:

1. id_ed25519.pub
2. id_ed25519

Varje fil innehåller varsin nyckel. id_ed25519.pub är den publika nyckeln och det är den som ska läggas in på de enheter som du vi koppla upp mot med din SSH-nyckel.

id_ed25519 är den privata nyckeln som bör nästan aldrig får lämnas ut till någon. Kommer denna nyckel på villovägar kan vem som helst logga in på de datorer som du har installerat din publika nyckel. Hela säkerhetstänkandet med SSH-nycklar är att den privata nyckeln ska hålls hemlig. Låt dock id_ed25519 filen ligga orörd i .ssh mappen.

Sista steget för att få SSH-nyckeln att fungera är att överföra publiken nyckeln till den eller de servrar och datorer (med SSH-server mjukvaran installerad) som är tänkt att kunna loggas in utan lösenord. Smidigaste sättet är att köra följande kommando:

ssh-copy-id användare@server-adress

Eller om ssh-copy-id kommandot inte finns eller har  annan port än 22, använd:

cat ~/.ssh/id_ed25519.pub | ssh användare@server-adress -p 22 "cd ~/; mkdir .ssh; chown -R användare:användare .ssh; chmod 700 .ssh; cat >> .ssh/authorized_keys; chmod 600 .ssh/authorized_keys"

Vill man så kan man förstås manuellt kopiera innehållet i id_ed25519.pub och klistra in det längst ned i filen authorized_keys på serven.

Har servern inte stöd för ed25519 nycklar så kan man istället använda 4096 bitars RSA nyckel som än så länge anses vara säker.

ssh-keygen -b 4096 -C användare@dator

Om du har genererat nycklar sedan tidigare som antingen är DSA, ECDSA eller RSA nyckel som är 2048 bitar eller lägre bör bytas ut omgående. Döp om nyckeln med ordet legacy eller liknade och generera nya nycklar enligt ovan. Anslut sedan till de enheter som har den gamla publika nyckeln och ersätt med den nya.

Om inloggningen fungerar som det ska så kan man se till att stänga av inlogging via lösenord genom att ändra SSH-konfigen till följande

PasswordAuthentication no
UsePAM no
ChallengeResponseAuthentication no

5. Säkra din SSH-klient

Om du redan har det, lägg till .ssh/config med följande innehåll:

Host *
Protocol 2

Den ser alltid till att använda enbart version 2 av SSH protokollet. SSH version 1 anses vara osäkert och ska inte längre användas.