Configurare un VPS Ubuntu per il primo sito HTTPS

Prepara dominio e accesso di recupero

L’esempio richiede una nuova VM Ubuntu 24.04, IPv4 pubblico, SSH sulla porta 22, un account iniziale con sudo e un dominio sotto il tuo controllo. Genera la chiave prima della creazione; se il server vuoto esiste già, usa il percorso alternativo attraverso un accesso funzionante.

I comandi client si eseguono sul computer in Bash per Linux, macOS o WSL; quelli server dentro SSH. Sostituisci 203.0.113.10 con il tuo indirizzo e app.example.com con il tuo nome host: sono esempi per documentazione. L’utente iniziale è ubuntu; usa quello fornito dal provider.

Apri la console di recupero prima di cambiare accessi o firewall. Fermati se i percorsi dell’esempio appartengono a un sito già attivo. Leggi le regole firewall dell’immagine: Oracle Cloud richiede il percorso distinto indicato sotto.

Genera una chiave o aggiungila tramite l’accesso esistente

Sul computer crea una chiave dedicata con passphrase. Se il nome è già usato, cambialo in tutti i passaggi. Solo il file .pub è pubblico; il privato rimane sul computer.

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

VPS nuovo: crea ora il server Ubuntu 24.04 e inserisci la chiave pubblica nel campo SSH del provider. Conferma il nome utente, salta i due blocchi per server esistente e passa alla verifica dell’impronta host.

VPS vuoto già creato: lascia aperta la sessione funzionante. Da un altro terminale locale copia la nuova chiave pubblica usando l’autenticazione già valida. Sostituisci existing_vps_key con il nome della chiave privata attuale. Se usi password o agente SSH, ometti -i ~/.ssh/existing_vps_key senza cambiare la politica di autenticazione.

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

Nella sessione server esistente valida il file pubblico e aggiungilo ad authorized_keys del tuo account iniziale. L’aggiunta conserva le chiavi esistenti; il separatore gestisce anche un’ultima riga senza newline. Senza accesso funzionante serve prima il recupero del provider.

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

In entrambi i percorsi, prima di accettare il primo collegamento confronta l’impronta con la chiave host corrispondente nella console attendibile. Per la chiave host Ed25519 esegui nella console:

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

Sul computer apri una connessione nuova con la chiave creata, mantenendo disponibile quella originale.

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

Da un altro terminale locale copia la chiave pubblica per l’amministratore separato. Ricopiare questo file pubblico temporaneo va bene se il percorso precedente lo ha già caricato.

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

Crea un amministratore e provalo separatamente

Sul server controlla prima getent passwd deploy: non deve restituire un account. Se deploy esiste, scegli un nome libero e sostituiscilo ovunque, inclusi gruppi e percorsi home, evitando di sovrascrivere chiavi altrui.

Controlla immagine e risorse, esamina gli aggiornamenti e crea l’amministratore. Imposta una password robusta per sudo. I comandi install assegnano proprietario e permessi limitati alla sua chiave.

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

Da un nuovo terminale del computer accedi come amministratore.

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

Nella nuova sessione server prova sudo. Dopo la password di deploy deve stampare root. Prosegui qui soltanto quando entrambi i controlli funzionano, mantenendo l’accesso originale.

sudo whoami

Installa Nginx e scegli il firewall compatibile

Sul server installa Nginx. Tieni aperti console e SSH: il firewall del provider e quello del guest controllano entrambi l’accesso.

sudo apt install nginx
sudo systemctl enable --now nginx

Nella rete del provider consenti TCP 22 dalla tua postazione amministrativa e TCP 80/443 per i visitatori. Se SSH usa un’altra porta, preservala. Il permesso nella rete non apre una porta bloccata dentro Ubuntu.

Immagini Ubuntu Oracle Cloud: salta l’intero blocco UFW seguente. Può interferire con regole essenziali dell’immagine e impedirne l’avvio. Conserva iptables, incluse le regole iSCSI per avvio e volumi. Configura security list o NSG OCI e le regole guest documentate per HTTP/HTTPS. Non svuotare le regole né sostituire i pacchetti firewall dell’immagine.

Altre immagini Ubuntu nuove compatibili con UFW: usa il blocco solo se il provider supporta UFW e non richiede una diversa gestione. Permetti la porta SSH effettiva prima di abilitarlo; qui è 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

Dopo entrambi i percorsi prova un nuovo accesso SSH. La vecchia sessione ancora aperta non è questa verifica. Deve riuscire anche il controllo HTTP esterno del prossimo passo, prima di richiedere il certificato.

Pubblica una pagina in un sito Nginx separato

Sul server crea una nuova document root e il suo server block. Sostituisci il nome host nel blocco. Conserva gli EOF fra apici, che impediscono alla shell di espandere variabili Nginx come $uri.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="it"><title>Prima pubblicazione</title><h1>Questa pagina viene servita dal VPS Ubuntu</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

Ricarica sul server solo se il controllo della configurazione riesce.

sudo systemctl reload nginx

Dal computer interroga quel nome all’indirizzo del VPS prima di cambiare DNS. Deve comparire il titolo della tua pagina, non il benvenuto predefinito di Nginx.

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

Collega DNS e attiva HTTPS

Crea il record A verso l’IPv4 del VPS. Pubblica AAAA solo se IPv6 funziona su quel server: un vecchio indirizzo può deviare utenti e validazione del certificato. L’esempio presuppone DNS diretto alla VM, senza proxy.

Dal computer richiedi http://app.example.com/ senza --resolve e continua quando risponde la tua pagina. Sul server usa Certbot e il plugin Nginx dell’archivio Ubuntu. Serve il repository Universe: risolvi eventuali pacchetti mancanti prima di andare avanti.

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

Segui le richieste di email e accettazione delle condizioni. Certbot modifica il sito e attiva il redirect HTTP→HTTPS. Verifica il timer; se è inattivo abilitalo con sudo systemctl enable --now certbot.timer. Mantieni la porta 80 raggiungibile per validazione e rinnovo HTTP.

Verifica dall’esterno e dopo un riavvio

Sul computer controlla redirect, certificato e contenuto. HTTP deve rinviare a HTTPS; HTTPS deve riuscire e mostrare la tua pagina. Non aggiungere -k a curl: nasconderebbe errori di validazione.

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

Finché è un ambiente di prova, esegui sudo reboot sul server. Al ritorno accedi come deploy, controlla systemctl is-active nginx e ripeti la richiesta HTTPS esterna. Il riavvio chiude SSH intenzionalmente; usa la console se la macchina non torna.

Risolvi un controllo fallito e conserva il lavoro

Scorri la tabella per vedere le altre colonne →

Per l’accesso usa la diagnosi degli errori SSH prima di cambiare impostazioni. Conserva fuori dal VPS file, configurazione Nginx, DNS e istruzioni di ricostruzione. Se copi chiavi TLS private, proteggile separatamente. Aggiungi avvisi per disponibilità e scadenza: un controllo riuscito oggi non sorveglia il rinnovo futuro.

La prova di backup e ripristino verifica file statici senza sovrascrivere il sito. Il recupero completo richiede anche gli altri asset, certificati e servizi. Database e runtime hanno una propria configurazione e procedura di copia; quando li aggiungi misura il carico con i criteri di dimensionamento.

Domande e risposte