Så kommer du igång med din första VPS - Steg för steg

Du har bestämt dig för en VPS, klickat på beställ och fått ett mail med en IP-adress och ett root-lösenord. Den här guiden tar dig från den nyprovisionerade servern till en fungerande webbsajt med HTTPS på sju steg. Inga omvägar och inga onödiga fördjupningar, bara den kortaste vägen till ett resultat du kan bygga vidare på.

Kommandona är testade på Ubuntu 22.04 och Debian 12. Principerna gäller för alla Debian-baserade distributioner med minimala justeringar. Windows Server täcks inte alls.

Är du fortfarande osäker på om VPS passar dina behov? Läs VPS-guiden innan du fortsätter. Har du inte bestämt dig mellan managed och unmanaged ännu? Det beslutet äger guiden om managed vs unmanaged VPS. Den här guiden förutsätter att du valt unmanaged VPS (eller managed med full SSH-åtkomst) och är redo att konfigurera. Vill du i stället börja med att jämföra leverantörer och priser hittar du aktuell data i jämförelseverktyget för VPS.

Nedan följer en snabb överblick över vad du gör och vad du behöver ha förberett.

Vad du kommer göra i den här guiden

Guiden täcker sju steg: SSH-inloggning, användarkonto, SSH-härdning, brandvägg, webbserver, DNS och HTTPS. Det är inte en sysadminkurs utan det obligatoriska minimumet för en fungerande webbserver på din egen VPS.

Det här gör du i guiden

1. Logga in på din VPS för första gången via SSH
2. Skapa ett säkert användarkonto
3. Stäng av root-inloggning och säkra SSH
4. Sätta upp en grundläggande brandvägg med UFW
5. Installera en webbserver (Nginx eller Apache)
6. Peka din domän mot servern
7. Aktivera HTTPS med ett gratis SSL-certifikat via Let's Encrypt

Det här behöver du innan du börjar

• En VPS med Ubuntu 22.04 eller Debian 12 installerat
• Root-inloggningsuppgifter från din leverantör (IP-adress och lösenord, eller SSH-nyckel)
• En registrerad domän med möjlighet att ändra DNS-inställningar
• En dator med SSH-klient (inbyggt i macOS och Linux, Windows Terminal eller PuTTY på Windows)

Realistisk tidsuppskattning: 30-90 minuter beroende på förkunskaper. Det tar längre tid första gången. Det är normalt och ingenting att oroa sig för.

Steg 1. Logga in på din VPS via SSH

SSH är det krypterade protokollet som låter dig styra servern via kommandoraden på distans. Det är grunden för allt som följer i den här guiden. Utan en fungerande SSH-anslutning kan du inte göra något annat.

Det grundläggande kommandot ser ut så här:

ssh root@din-server-ip

Kommandot består av tre delar. ssh är programmet, root är användaren du loggar in som och din-server-ip ersätter du med den IP-adress din leverantör gett dig.

Första gången du ansluter till en ny server visas en fingerprint-varning som kan se ut ungefär så här:

The authenticity of host '12.34.56.78 (12.34.56.78)' can't be established.
ED25519 key fingerprint is SHA256:xxxxx...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Det här är inte ett tecken på att något är fel. Det är en engångskontroll. Skriv yes och tryck Enter. Serverns fingerprint sparas lokalt och du slipper frågan nästa gång. Om varningen däremot dyker upp igen för en server du redan anslutit till är det ett tecken på att något förändrats, och du bör undersöka det innan du fortsätter.

Har du fått en SSH-nyckel istället för lösenord?

Vissa leverantörer ger en SSH-nyckel snarare än ett tillfälligt root-lösenord. Då anger du nyckeln med flaggan -i:

ssh -i ~/.ssh/din-nyckel root@din-server-ip

Använder du Windows? Windows Terminal fungerar utmärkt och är förinstallerat på moderna Windows-versioner. Du hittar det i startmenyn. Alternativt fungerar PuTTY, men märk att PuTTY använder sitt eget nyckelformat (.ppk). Du kan behöva konvertera nyckeln till OpenSSH-format om din leverantör skickat en PuTTY-nyckel.

Steg 2. Skapa ett säkert användarkonto

Nu är du inloggad som root. Root har oinskränkt tillgång till hela systemet. Ett enda felskrivet kommando eller ett komprometterat konto kan radera allt på servern utan möjlighet till ångra. Det är anledningen till att du inte bör arbeta som root i vardagen.

Skapa ett nytt användarkonto med:

adduser dittanvandarnamn

Du ombeds välja ett lösenord och fylla i ett par valfria uppgifter (tryck Enter för att hoppa över dem). Ge sedan den nya användaren sudo-rättigheter:

usermod -aG sudo dittanvandarnamn

Sudo låter användaren utföra adminkommandon men kräver explicit godkännande för varje privilegierat kommando. Det loggar vad som körs, vilket root-sessioner inte gör. Det är alltså inte bara bekvämare utan faktiskt säkrare.

Uppdatera nu systemet som ett naturligt första sudo-kommando, direkt efter att du loggat in som den nya användaren. Öppna en ny terminal och logga in:

ssh dittanvandarnamn@din-server-ip

Verifiera att sudo fungerar:

sudo whoami

Om svaret är root fungerar allt korrekt. Kör sedan systemuppdateringen:

sudo apt update && sudo apt upgrade -y

Håll kvar den inloggade root-sessionen öppen tills du bekräftat att den nya användaren fungerar. Det är just den säkerhetsmarginalen som förhindrar att du låser ut dig själv i nästa steg.

Steg 3. Stäng av root-inloggning och säkra SSH

Nyprovisionerade servrar på port 22 är ett favoritmål för automatiserade brute-force-attacker. De startar inom minuter efter att en server getts en publik IP-adress. Nästan alltid attackeras root-kontot eftersom det existerar på alla Linux-servrar och därmed är ett förutsägbart mål. Nästa steg stänger den vägen helt.

OBS: Gör detta i en separat session, parallellt med en session där du är inloggad som din vanliga sudo-användare. Om du stänger av root-SSH utan att ha bekräftat att sudo-användaren fungerar låser du ut dig från servern.

Öppna SSH-konfigurationsfilen:

sudo nano /etc/ssh/sshd_config

Hitta raden som lyder PermitRootLogin yes och ändra den till:

PermitRootLogin no

Spara filen med Ctrl+O och avsluta med Ctrl+X. Starta om SSH-tjänsten för att ändringen ska träda i kraft:

sudo systemctl restart sshd

Verifiera genom att försöka logga in som root i ett nytt terminalfönster. Du ska nekas åtkomst.

En vanlig åtgärd som minskar brus i serverloggarna är att byta SSH-port från standardporten 22 till ett annat tal, till exempel 2222. Det är inte en säkerhetsåtgärd i egentlig mening. En angripare som letar aktivt hittar porten ändå, men det reducerar automatiserade scan-attacker dramatiskt. Om du byter port, uppdatera UFW-reglerna i nästa steg med den nya porten.

För den som har SSH-nyckel på plats kan lösenordsbaserad inloggning inaktiveras helt med PasswordAuthentication no i samma konfigurationsfil. Det är det som faktiskt ger starkt skydd mot brute-force. Gör det enbart om du vet att SSH-nyckeln fungerar, annars låser du ut dig själv utan reservväg.

Vill du stärka säkerheten ytterligare efter den här guiden? Verktyget fail2ban automatiserar blockering av IP-adresser som upprepade gånger misslyckas med inloggning och är ett naturligt nästa steg.

Steg 4. Sätt upp brandväggen (UFW)

UFW, eller Uncomplicated Firewall, är Ubuntus och Debians standardverktyg för att hantera brandväggsregler. Det förenklar den underliggande iptables-konfigurationen till läsbara kommandon. Principen är enkel. Allt inkommande som inte är explicit tillåtet blockeras.

OBS: Tillåt SSH-trafik INNAN du aktiverar brandväggen. Gör du det i fel ordning stänger du ute dig själv från servern.

Kör kommandona i exakt den här ordningen:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Det första kommandot tillåter SSH-trafik (port 22). Om du bytte SSH-port i förra steget, ersätt OpenSSH med din port: sudo ufw allow 2222/tcp. Port 80 är HTTP och port 443 är HTTPS. Båda behövs för att din webbserver ska nå besökarna.

Verifiera att reglerna är rätt:

sudo ufw status

Du ska se att SSH, port 80 och port 443 är tillåtna. En aktiv UFW-status bekräftar att brandväggen körs.

UFW är ett viktigt lager men inte det enda du behöver. Uppdateringar, SSH-konfiguration och starka lösenord är lika viktiga delar av en säker server. Om din leverantör erbjuder en nätverksbrandvägg är det ett komplement och inte ett alternativ till den lokala brandväggen. Ha båda.

Steg 5. Installera en webbserver

Med SSH, säkert användarkonto och brandvägg på plats är det dags att göra servern till en faktisk webbserver. Det finns två etablerade val. Nginx är händelsedriven och hanterar hög belastning och statiskt innehåll effektivt. Apache är mer utbrett, flexibelt och lättare att konfigurera för PHP-applikationer via .htaccess-filer. Vill du förstå skillnaderna och prestandaaspekterna mer ingående hittar du det i guiden om LiteSpeed, Nginx och Apache.

Välj ett av spåren nedan. Du behöver bara installera ett av dem.

Alternativ A: Nginx

sudo apt install nginx -y

Verifiera att tjänsten körs:

sudo systemctl status nginx

Status ska visa active (running). Öppna din server-IP i webbläsaren och bekräfta att du ser Nginxs välkomstsida. Det bekräftar att webbservern svarar och att port 80 är öppen i brandväggen.

Vill du köra PHP (vilket de flesta CMS kräver, inklusive WordPress):

sudo apt install php php-fpm php-mysql -y

PHP-FPM är den rekommenderade PHP-processhanteraren med Nginx och installeras automatiskt i kommandot ovan.

Alternativ B: Apache

sudo apt install apache2 -y

Verifiera:

sudo systemctl status apache2

Öppna din server-IP i webbläsaren och bekräfta att Apaches välkomstsida visas. PHP för Apache installeras med:

sudo apt install php libapache2-mod-php php-mysql -y

Var lägger du dina filer?

Standardmappen för din webbsajts filer kallas document root. För båda webbservrarna är den som standard /var/www/html/. Ersätt den befintliga index.html med din egen fil för att verifiera att webbservern faktiskt serverar ditt innehåll:

echo "Hej från min VPS" | sudo tee /var/www/html/index.html

Ladda om sidan i webbläsaren. Ser du din text är allt korrekt konfigurerat.

Föredrar du ett grafiskt gränssnitt för serverhantering är kontrollpaneler som Webmin eller ISPConfig ett alternativ som ger webbaserad administration i stället för kommandoraden. Att installera och konfigurera dem är dock utanför den här guidens scope. Databasinstallation (MySQL eller MariaDB) är ett naturligt nästa steg för de flesta applikationer men tillhör inte det obligatoriska minimum för att komma igång.

Steg 6. Peka din domän mot servern

Servern är uppe, men för att besökare ska nå den via ett domännamn måste du koppla domänen till serverns IP-adress. Det gör du med ett DNS A-record, ett enkelt pekdon som säger att det här domännamnet leder till den här IP-adressen.

Logga in hos din domänregistrar (det kan vara det företag där du köpt domänen) och hitta DNS-inställningarna. Du behöver lägga till:

• Ett A-record för @ (rotkatalogen, dvs. dindomän.se) som pekar mot din server-IP
• Ett A-record för www som pekar mot samma IP, om du vill att www.dindomän.se också ska fungera

Notera TTL-värdet för dina DNS-poster. TTL (Time To Live) styr hur länge DNS-informationen cachas längs vägen. Sätt TTL till 300 sekunder (5 minuter) innan du gör ändringen om du vill att den sprider sig snabbt. Standard-TTL på 3600 sekunder innebär att ändringen kan ta upp till en timme att nå alla besökare. I värsta fall, om tidigare DNS-poster hade höga TTL-värden, kan det ta upp till 48 timmar.

Verifiera att domänen pekar rätt med:

ping dindomän.se

IP-adressen i svaret ska matcha din server-IP. Alternativt kan du använda ett DNS-lookup-verktyg online om ping är blockerat i din miljö.

Du behöver inte flytta domänen till din VPS-leverantör. Domänen kan ligga kvar hos registraren och du ändrar bara DNS-pekarna, inte ägarskapet. Det är en vanlig missuppfattning som ibland leder till onödigt arbete.

Steg 7. Aktivera HTTPS med Let's Encrypt

En sajt utan HTTPS visas som "Inte säker" i moderna webbläsare. Det skrämmer bort besökare och signalerar till sökmotorerna att sajten inte är välskött. Att aktivera HTTPS med Let's Encrypt är gratis och tar några minuter.

Let's Encrypt är en automatiserad certifikatutfärdare som ger 90-dagars SSL-certifikat. Det är numera branschstandard och används av en stor andel av de sajter på internet som kör HTTPS. Certifikaten förnyas automatiskt och kräver ingen manuell åtgärd efter att allt är på plats.

OBS: Din domän måste peka mot servern INNAN du kör certbot. Let's Encrypt verifierar domänägarskapet via HTTP och kan inte utfärda certifikat om DNS inte är korrekt konfigurerat. Ordningsföljden i den här guiden respekterar detta.

Installera certbot:

sudo apt install certbot -y

Installera sedan det webbserver-specifika pluginet för din webbserver.

Nginx

sudo apt install python3-certbot-nginx -y
sudo certbot --nginx -d dindomän.se -d www.dindomän.se

Apache

sudo apt install python3-certbot-apache -y
sudo certbot --apache -d dindomän.se -d www.dindomän.se

Certbot ber dig ange en e-postadress (för certifikatförnyelsepåminnelser) och godkänna användarvillkoren. Välj att omdirigera all HTTP-trafik till HTTPS när du tillfrågas. Det är rätt val för de allra flesta sajter.

Sedan sker följande automatiskt. Certbot hämtar certifikatet, konfigurerar din webbserver att använda det och ställer in en omdirigering från HTTP till HTTPS.

Verifiera att automatisk förnyelse fungerar:

sudo certbot renew --dry-run

Om kommandot körs utan fel är allt korrekt inställt. Let's Encrypt-certifikat löper ut efter 90 dagar och förnyas sedan automatiskt via ett schemalagt systemjobb utan att du behöver göra något.

Let's Encrypt-certifikat ger kryptering som är likvärdig med betalda certifikat för de allra flesta användningsfall. Betalda certifikat tillför OV- och EV-validering, vilket är relevant för finansiella tjänster och myndigheter men inte för en vanlig webbsajt eller applikation.

Verifiera att allt fungerar

Innan du går vidare, kör igenom den här checklistan och bekräfta att varje punkt stämmer. Det är enklare att felsöka ett steg i taget nu än att jaga ett ackumulerat fel längre fram.

1. SSH-inloggning som vanlig användare (inte root) fungerar
2. sudo whoami returnerar root från din vanliga användare
3. Root-inloggning via SSH nekas. Försök logga in som root och bekräfta att det misslyckas
4. sudo ufw status visar att UFW är aktivt med rätt regler för SSH, port 80 och 443
5. sudo systemctl status nginx (eller apache2) visar active (running)
6. Din domän öppnar sajten i webbläsaren via http://
7. HTTPS fungerar. Webbläsaren visar låsikonen och certifikatinformationen pekar mot Let's Encrypt

Om en punkt saknas är det inte ett skäl att börja om. Varje steg i den här guiden är oberoende och kan åtgärdas separat. Gå tillbaka till det aktuella steget och läs igenom instruktionerna igen.

Säkerställ också att webbservern startar automatiskt om servern startar om:

sudo systemctl enable nginx

Ersätt nginx med apache2 om du valt Apache.

Servern är igång, nu börjar det riktiga arbetet

Servern är konfigurerad med grundläggande säkerhet och serverar din sajt via HTTPS. Det är ett gott resultat. Men det är en startpunkt och inte ett slutläge.

En sak bör komma högt upp på listan direkt efter att du gått igenom den här guiden. Backup. En server utan fungerande backuprutin är alltid en risk, oavsett hur säkert allt annat är. Guiden om backup-strategi för webbplatser går igenom vad du bör tänka på och hur du sätter upp ett hållbart upplägg.

För de flesta är de naturliga nästa stegen databasinstallation (MySQL eller MariaDB) och sedan installation av ett CMS. Vill du installera WordPress på din nya server hittar du installationsinstruktioner i WordPress.org:s officiella dokumentation. Kolla också om din leverantör erbjuder en one-click-installation via sin kontrollpanel.

Funderar du på vilken webbserver som passar din sajt och dina prestandakrav? Den frågan ger guiden om LiteSpeed, Nginx och Apache ett genomarbetat svar med en tydlig jämförelse.

Tre säkerhetsåtgärder är naturliga nästa steg men faller utanför den här guidens scope. fail2ban för automatisk blockering av brute-force-försök, unattended-upgrades för automatiska säkerhetsuppdateringar och loggövervakning av auth.log för att identifiera ovanlig aktivitet. Löpande underhåll i form av uppdateringar och loggövervakning är ett kontinuerligt arbete.

Har du kommit igång och märker att unmanaged kräver mer arbete än du räknat med? Det är en vanlig insikt efter den första servern. Alternativet beskrivs i guiden om managed VPS. Undrar du i stället om det överhuvudtaget var rätt timing att uppgradera till VPS? Den frågan äger guiden om när det är dags att uppgradera till VPS.

Vill du jämföra fler leverantörer? På jämförelseverktyget för VPS kan du filtrera på specifikationer, hanterad nivå och pris med aktuell data. Letar du specifikt efter ett alternativ med svenska datacenter och managed-nivå är GleSYS värt ett besök, ett av de mer erfarna svenska VPS-alternativen med datacenter i Stockholm. Föredrar du att slippa serverhanteringen helt och hållet och bara fokusera på WordPress är Templ ett managed WordPress-alternativ som tar hand om det tekniska lagret.