Innehåll
Förbered en ny server och en domän
Använd en ny, tom Ubuntu 24.04 VPS med offentlig IPv4, SSH på port 22 och ett första konto med sudo. Skapa nyckeln innan du beställer instansen. Har du redan en server med data eller annan konfiguration, granska den separat i stället för att köra denna nya installation rakt av.
Lokala kommandon använder Bash på Linux, macOS eller WSL; serverkommandon körs i SSH. Byt 203.0.113.10 till din adress, app.example.com till din domän och ubuntu till leverantörens inledande konto. Öppna återställningskonsolen. Stoppa om exempelsökvägarna redan hör till en installation.
Skapa nyckeln och verifiera första anslutningen
Kör lokalt. Välj ett annat filnamn genom hela guiden om filen redan finns och ange en lösenfras.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubBeställ därefter servern och ange endast innehållet i .pub-filen i fältet för SSH-nyckel. Den privata nyckeln ska stanna på datorn. Innan första SSH-inloggningen jämför du serverns fingeravtryck via den betrodda återställningskonsolen. För en Ed25519-värdnyckel körs detta i konsolen:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubAnslut från din dator och acceptera bara en matchande värdnyckel:
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Behåll sessionen. Kopiera från en annan lokal terminal den publika nyckeln som den nya administratören ska använda:
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubSkapa en separat administratör
Kontrollera först getent passwd deploy på servern. Inget konto ska visas. Finns deploy redan, välj ett oanvänt namn och byt även grupp och hemsökvägar genom hela guiden så att ingen annans nyckelfil ersätts.
Kör på servern. Granska uppdateringarna och ange ett starkt lösenord för administratörens sudo-frågor.
cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keysÖppna en ny lokal terminal och testa kontot:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10I den nya serversessionen:
sudo whoamiResultatet ska vara root när sudo godtar lösenordet. Fortsätt i den nya sessionen men behåll den ursprungliga åtkomsten tills allt fungerar.
Installera Nginx och välj rätt brandväggsmetod
Kör på servern:
sudo apt install nginx
sudo systemctl enable --now nginxI leverantörens brandvägg tillåts TCP 22 från din administrationsadress och 80/443 för webbplatsens besökare. Bevara den verkliga SSH-porten om den avviker. Både leverantörens nätregler och gästsystemets regler måste tillåta trafiken.
Oracle Cloud Ubuntu: hoppa över hela UFW-blocket nedan. Bevara avbildningens iptables-regler och skyddet för iSCSI boot- och blockvolymer. Använd OCI security lists eller NSG och den dokumenterade gästkonfigurationen för HTTP/HTTPS. Töm inte reglerna och byt inte brandväggspaket.
Andra nya Ubuntu-avbildningar: använd följande enbart om leverantören stöder UFW och inte kräver en annan hanterad brandvägg. Tillåt rätt SSH-port före aktivering; exemplet antar 22.
sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseTesta en helt ny SSH-inloggning efter vald brandväggsmetod. En gammal session är inte samma kontroll. Behåll konsolen och fungerande åtkomst medan eventuella fel utreds.
Publicera en separat Nginx-webbplats
Kör på servern och ersätt värdnamnet i blocket. Behåll de citerade EOF-markörerna så att skalet inte expanderar Nginx-variabler som $uri.
sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="en"><title>First deployment</title><h1>Ubuntu VPS is serving this page</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
listen 80;
listen [::]:80;
server_name app.example.com;
root /var/www/first-site;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -tLadda om bara om konfigurationstestet lyckas:
sudo systemctl reload nginxKontrollera från din dator före DNS-ändringen. Du ska få exempelsidans rubrik och inte standardsidan från Nginx.
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/Koppla DNS och aktivera HTTPS
Skapa en A-post för värdnamnet till rätt IPv4. Skapa AAAA bara om IPv6 fungerar på denna server; en felaktig AAAA-post kan skicka besökare och certifikatkontroller fel. Exemplet använder direkt DNS utan proxy.
Begär lokalt http://app.example.com/ utan --resolve. Fortsätt när rätt sida visas. Installera sedan Certbot på servern från Ubuntu-arkivet; paketen kräver Universe. Lös ett eventuellt package-not-found-fel innan nästa steg.
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timerFölj frågorna om e-post och villkor. Certbot ändrar denna webbplats och lägger till HTTP → HTTPS. Kontrollera förnyelsetimern; om den är inaktiv, använd sudo systemctl enable --now certbot.timer. Behåll port 80 tillgänglig för validering och förnyelse.
Verifiera utifrån och efter omstart
Kör på din dator. HTTP ska omdirigeras, HTTPS ska lyckas och rätt innehåll visas. Använd inte curl -k, som döljer certifikatfel.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/På den ännu disponibla testservern: kör sudo reboot. Anslut igen som deploy, kontrollera systemctl is-active nginx och upprepa HTTPS-testet. Omstart avslutar SSH; använd konsolen om maskinen inte kommer tillbaka.
Följ upp fel och återställning
På en liten skärm kan du rulla tabellen i sidled för att se alla kolumner.
| Symtom | Kontrollera först |
|---|---|
| SSH timeout | Adress, nätregler, gästbrandvägg och konsol |
| Permission denied | Konto, nyckel och rättigheter |
| Nginx standardsida | DNS, server_name och aktiverad webbplats |
| Certifikatfel | A/AAAA och publik port 80 |
| Fel efter ändring | nginx -t och Nginx-journalen |
Följ diagnosen för det exakta SSH-felet innan du ändrar åtkomstinställningar. Spara filer, konfiguration, DNS och installationssteg utanför servern. Öva en separat filåterställning och planera skydd för certifikatnycklar.
Detta är en statisk webbplats. Databas och applikationsruntime behöver egna tjänsteinställningar, hälsokontroller och konsistent backup. Lägg till larm för tillgänglighet och certifikatutgång; en lyckad kontroll idag övervakar inte morgondagen.
För en ny Ubuntu 24.04-server med direkt DNS och SSH på port 22. Följ leverantörens brandväggsregler; OCI Ubuntu ska hoppa över UFW. Proceduren är dokumentationsbaserad, inte testad på alla leverantörsavbildningar.
Vanliga frågor
Kan jag köra detta på min befintliga webbplats?
Börja på en separat testserver. Guiden skapar filer, aktiverar nätregler och låter Certbot ändra Nginx. En befintlig miljö kräver genomgång av nuvarande konfiguration och återställning.
Installeras WordPress eller en databas?
Nej, resultatet är statisk HTTPS-hosting. Lägg till applikationen separat och testa start, funktioner och datåterställning.