Ubuntu VPS-oppsett for din første nettside

Avklar forutsetninger og behold gjenoppretting

Bruk en ny server med offentlig IPv4, SSH på port 22, en første konto med sudo og et domene du kontrollerer. Lokale kommandoer bruker Bash på Linux, macOS eller WSL. Serverkommandoer kjøres inne i SSH. Stopp hvis eksempelstiene allerede tilhører et eksisterende nettsted.

Erstatt 203.0.113.10, app.example.com og startkontoen ubuntu med dine verdier. Åpne leverandørens gjenopprettingskonsoll før tilgang eller nettverk endres. Oracle Ubuntu-images skal hoppe over UFW-grenen nedenfor.

Klargjør og prøv en ny SSH-nøkkel

På din egen maskin oppretter du et nøkkelpar med passfrase. Bruk et annet filnavn gjennom hele veiledningen hvis navnet allerede finnes. Den private nøkkelen skal ikke lastes opp.

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub

Ny instans: opprett Ubuntu 24.04-serveren med .pub-filen i leverandørens nøkkelfelt. Bekreft brukernavnet. Hopp over de to neste kodeblokkene for en allerede opprettet server.

Eksisterende, tom testserver: behold fungerende tilgang. Fra en annen lokal terminal kopierer du den nye offentlige nøkkelen med autentiseringen som allerede virker. Erstatt existing_vps_key med riktig privat nøkkel. Ved passord eller SSH-agent utelater du -i-argumentet uten å endre serverens autentiseringsregler.

scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

I den eksisterende serverøkten kontrollerer du den opplastede offentlige nøkkelen og legger den til for din egen startkonto. Blokken beholder eksisterende authorized_keys-oppføringer. Uten fungerende tilgang må du først bruke leverandørens gjenoppretting.

if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    printf '\n' >> ~/.ssh/authorized_keys
    cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
fi

Før første nye tilkobling sammenligner du fingeravtrykket med riktig vertsnøkkel i den pålitelige konsollen. For Ed25519 brukes følgende konsollkommando:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Koble til fra en ny terminal på din egen maskin og behold den gamle økten til dette fungerer.

ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Fra en annen lokal terminal kopierer du den offentlige nøkkelen som skal brukes av den separate administratorkontoen. Det er greit å kopiere denne midlertidige offentlige filen på nytt.

scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Opprett en separat administrator

Kontroller først getent passwd deploy på serveren. Hvis kontoen finnes, velg et ubrukt navn og endre alle konto-, gruppe- og hjemmestier i eksemplet. Ellers kan du erstatte en annen brukers nøkkelfil.

Se gjennom system og oppgraderinger. Velg et sterkt passord for den nye kontoens sudo-spørsmål. Filkommandoene setter eierskap og begrensede rettigheter.

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

Prøv kontoen fra en ny lokal terminal:

ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10

I den nye serverøkten kontrollerer du sudo. Forvent root etter at passordet er godtatt. Fortsett i denne økten og behold opprinnelig tilgang.

sudo whoami

Installer Nginx og velg riktig brannmurgren

På serveren installerer og starter du Nginx. Både leverandørens nettverksregler og gjestebrannmuren må tillate trafikken.

sudo apt install nginx
sudo systemctl enable --now nginx

Tillat TCP 22 fra administrasjonsstedet og TCP 80/443 for besøkende i leverandørens brannmur. Bevar den faktiske SSH-porten hvis den avviker.

Oracle Cloud Ubuntu: hopp over hele UFW-blokken. Oracle beskriver konflikter med nødvendige image-regler som kan hindre oppstart. Behold iptables-reglene, særlig for iSCSI-volumer. Bruk OCI security lists eller NSG og dokumenterte gjesteregler for HTTP/HTTPS. Ikke tøm eksisterende regler.

Andre nye Ubuntu-images: bruk UFW bare når leverandøren støtter det og ingen annen styrt brannmur kreves. Åpne faktisk SSH-port før aktivering; her er den 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 verbose

Test en helt ny SSH-tilkobling etter begge grenene. En eksisterende økt beviser ikke at ny innlogging er mulig. Hold gjenopprettingskonsollen tilgjengelig.

Publiser en egen Nginx-side

Kjør på serveren og bytt domenet inne i blokken. Behold de siterte EOF-markørene slik at skallet ikke utvider Nginx-variabler som $uri. Eksempelsiden beholder den engelske teksten fra originalkommandoen.

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 -t

Last inn konfigurasjonen på nytt bare når nginx -t lykkes.

sudo systemctl reload nginx

På din egen maskin prøver du domenet direkte mot adressen før DNS endres. Forvent eksempeloverskriften, ikke standardvelkomsten fra Nginx.

curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/

Koble domenet til HTTPS

Opprett en A-post mot serverens IPv4. Legg bare til AAAA dersom IPv6 faktisk virker; en gammel IPv6-post kan sende valideringen til feil maskin. Eksemplet bruker direkte DNS uten proxy.

Prøv http://app.example.com/ fra egen maskin uten --resolve. Når riktig side svarer, installerer du Certbot fra Ubuntu-arkivet. Pakkene trenger Universe; løs en eventuell manglende pakke før du går videre.

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.timer

Følg spørsmålene om e-post og vilkår. Certbot endrer Nginx-oppsettet og legger til videresending fra HTTP til HTTPS. Kontroller at certbot.timer er planlagt; ved inaktiv timer brukes sudo systemctl enable --now certbot.timer. Port 80 må fortsatt nås for validering og fornyelse.

Kontroller fra utsiden og etter omstart

Kjør lokalt. HTTP skal videresende, og HTTPS skal vise siden med et gyldig sertifikat. Ikke legg til -k: det skjuler valideringsfeil.

curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/

Mens dette fortsatt er et testoppsett, kjører du sudo reboot på serveren. Koble til som deploy når den er tilbake, kontroller systemctl is-active nginx og gjenta HTTPS-kontrollen utenfra. Bruk konsollen hvis serveren ikke kommer tilbake.

Ved feil side sjekker du DNS, server_name og aktivert nettsted. Ved sertifikatfeil sjekker du A/AAAA og port 80. Ved Nginx-feil bruker du nginx -t og tjenesteloggen. Tilgangsproblemer behandles i SSH-veiledningen.

Lagre filer, Nginx-konfigurasjon, DNS og gjenoppbyggingsnotater utenfor VPS-en. Test en separat gjenoppretting. Beskytt eventuelle private sertifikatnøkler. Legg til varsler for tilgjengelighet og sertifikatutløp. Dette oppsettet serverer statiske filer; en database trenger egen konfigurasjon og kopimetode.

Spørsmål og svar