Primo setup di un VPS Ubuntu 26.04: utente sudo, chiavi SSH, UFW e aggiornamenti

Un VPS appena creato è raggiungibile da tutta Internet già dal primo minuto, e i tentativi automatici di accesso SSH arrivano molto prima di quanto si pensi. Questa guida mette in sicurezza un server Ubuntu 26.04 LTS (o Debian 13) in circa un quarto d’ora: utente amministrativo, chiavi SSH, password disattivate, firewall, aggiornamenti automatici e qualche ritocco utile, con un controllo concreto dopo ogni passo.

Versioni di riferimento: Ubuntu 26.04 LTS (OpenSSH 10.2, UFW 0.36.2, unattended-upgrades 2.12), Debian 13 “trixie” per le differenze segnalate. Procedura verificata sulla documentazione ufficiale al 4 novembre 2026.

Prima di cominciare: la regola della seconda sessione

L’unico modo per rovinare questa procedura è chiudersi fuori dal server. Per questo vale una regola semplice: ogni volta che toccate SSH o il firewall, lasciate aperta la sessione attuale e provate l’accesso da una seconda finestra del terminale. Chiudete la prima solo quando la seconda funziona.

Come rete di sicurezza, individuate subito nel pannello del provider la console web (spesso chiamata VNC, KVM o “console”): permette di entrare anche quando SSH non risponde. Sapere dov’è prima di averne bisogno fa risparmiare molto tempo. Se il VPS ospita già dati, fate uno snapshot dal pannello prima di iniziare.

Passo 1: aggiornare il sistema

Collegatevi con le credenziali ricevute (sostituite IP_VPS con l’indirizzo del server) e aggiornate tutto prima di qualsiasi altra cosa:

ssh root@IP_VPS
apt update
apt full-upgrade

Se l’aggiornamento ha installato un nuovo kernel, riavviate con reboot e ricollegatevi dopo un minuto.

Passo 2: creare un utente amministrativo

Lavorare sempre come root è scomodo da proteggere e rischioso negli errori di battitura. Create un utente vostro (al posto di NOMEUTENTE) e aggiungetelo al gruppo sudo:

adduser NOMEUTENTE
usermod -aG sudo NOMEUTENTE

adduser chiede una password: sceglietene una robusta, servirà per sudo anche quando l’accesso SSH sarà solo a chiave.

Passo 3: generare la chiave SSH sul vostro PC

La chiave si crea sul computer da cui vi collegate, non sul server. La documentazione di Ubuntu consiglia l’algoritmo Ed25519, che è anche quello predefinito delle versioni recenti di ssh-keygen. Il comando è identico su Linux, macOS e Windows (in PowerShell o nel Prompt dei comandi):

ssh-keygen -t ed25519 -C "NOMEUTENTE@pc-di-casa"

Accettate il percorso proposto e impostate una passphrase: se qualcuno vi ruba il file della chiave privata, senza passphrase ha in mano il server. Il risultato sono due file in .ssh nella vostra cartella utente: id_ed25519 (privata, non va mai copiata altrove) e id_ed25519.pub (pubblica, va sul server).

Passo 4: copiare la chiave pubblica sul server

Da Linux e macOS

ssh-copy-id -i ~/.ssh/id_ed25519.pub NOMEUTENTE@IP_VPS

Da Windows

Windows non include ssh-copy-id. Il metodo più semplice è mostrare la chiave pubblica in PowerShell e incollarla a mano:

Get-Content $env:USERPROFILE.sshid_ed25519.pub

Copiate la riga che compare (inizia con ssh-ed25519), entrate nel server come NOMEUTENTE con la password e create il file delle chiavi autorizzate:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Nell’editor incollate la riga su una sola linea, salvate con Ctrl+O e uscite con Ctrl+X.

Passo 5: disattivare password e accesso di root

Ora che la chiave funziona, togliamo di mezzo le password via SSH, il bersaglio di quasi tutti gli attacchi automatici. Su Ubuntu il file principale /etc/ssh/sshd_config include all’inizio tutti i file /etc/ssh/sshd_config.d/*.conf, e per la maggior parte delle direttive OpenSSH usa il primo valore che incontra. I file inclusi vengono letti in ordine alfabetico: per essere sicuri che le vostre impostazioni vincano, date al file un nome che venga per primo.

sudo nano /etc/ssh/sshd_config.d/00-hardwarfare.conf

Contenuto del file:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Prima di riavviare, controllate la sintassi (la documentazione di Ubuntu lo raccomanda espressamente, perché una configurazione sbagliata può impedire a SSH di ripartire) e poi applicate:

sudo sshd -t
sudo systemctl restart ssh.service

Se sshd -T mostra ancora passwordauthentication yes, nella cartella sshd_config.d c’è un altro file che lo imposta prima del vostro (alcune immagini cloud lo aggiungono in fase di creazione): elencate i file con ls /etc/ssh/sshd_config.d/ e correggete il nome o il contenuto.

Passo 6: attivare il firewall UFW

UFW è il frontend per il firewall incluso in Ubuntu. Di default blocca tutto il traffico in entrata e consente quello in uscita. Prima di attivarlo bisogna permettere SSH, altrimenti la sessione cade. Il pacchetto di OpenSSH registra un profilo applicativo chiamato OpenSSH (porta 22/tcp):

sudo ufw allow OpenSSH
sudo ufw enable

UFW avvisa con Command may disrupt existing ssh connections. Proceed with operation (y|n)?: rispondete y, la regola appena aggiunta mantiene viva la sessione. Su Debian 13 UFW non è preinstallato: sudo apt install ufw.

Le altre porte si aprono solo quando servono: per un sito con Nginx sarà sudo ufw allow 'Nginx Full' (80 e 443). Molti provider offrono anche un firewall nel pannello, a monte del server: è un livello in più, ma ricordate di aprire lì le stesse porte.

Passo 7: aggiornamenti di sicurezza automatici

Su Ubuntu gli aggiornamenti di sicurezza non presidiati sono gestiti da unattended-upgrades. Assicuratevi che sia installato (se lo è già, il comando non fa nulla) e controllate che sia attivo:

sudo apt install unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Il file deve contenere entrambe le righe con valore "1":

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Su Debian 13 la wiki ufficiale suggerisce di attivarlo con sudo dpkg-reconfigure unattended-upgrades.

Di default il sistema non si riavvia da solo quando un aggiornamento (tipicamente il kernel) lo richiederebbe. Se il server può permettersi qualche minuto di fermo notturno, in /etc/apt/apt.conf.d/50unattended-upgrades potete togliere il commento e impostare Unattended-Upgrade::Automatic-Reboot "true"; e Unattended-Upgrade::Automatic-Reboot-Time "04:00";. L’orario segue il fuso del sistema: per questo il passo successivo conta.

Passo 8: fuso orario, nome host e swap

Molti VPS arrivano con fuso UTC. Per log e cron leggibili in ora italiana:

sudo timedatectl set-timezone Europe/Rome
timedatectl

Un nome host riconoscibile evita di lanciare comandi sul server sbagliato:

sudo hostnamectl set-hostname NOME-SERVER

I VPS più economici hanno 1–2 GB di RAM e spesso nessuna swap: un picco di memoria (un aggiornamento, un’importazione di database) può far intervenire il killer dei processi. Una swap su file da 2 GB fa da cuscinetto. Prima controllate con swapon --show che non ne esista già una: se l’elenco non è vuoto, saltate questo passo. Con util-linux recente (2.41 su Ubuntu 26.04), mkswap crea direttamente il file con i permessi corretti:

sudo mkswap --size 2G --file /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

La checklist dei primi 15 minuti

Se qualcosa va storto

• Permission denied (publickey). con la chiave giusta: quasi sempre sono i permessi. La documentazione di Ubuntu indica che solo l’utente deve poter scrivere su authorized_keys: dalla console web lanciate chmod 700 ~/.ssh e chmod 600 ~/.ssh/authorized_keys, e verificate che il file appartenga all’utente giusto. Per vedere il motivo dal lato server, sudo journalctl -fu ssh.service mentre ritentate l’accesso.
• La chiave ha una riga spezzata: se incollando da Windows la chiave finisce su più righe, OpenSSH non la riconosce. Riapritela con nano e riportatela su una sola linea.
• sshd -t restituisce un errore: indica file e riga. Correggete prima di riavviare; se avete già riavviato e SSH non risponde, entrate dalla console web e rinominate il vostro file in .conf.bak.
• La connessione si blocca dopo ufw enable: avete attivato il firewall senza la regola per SSH, oppure il server ascolta su una porta diversa dalla 22. Dalla console web: sudo ufw allow OpenSSH (o la porta reale), poi sudo ufw status.
• sudo: unable to resolve host dopo il cambio di nome: aggiungete il nuovo nome host alla riga 127.0.1.1 in /etc/hosts.

Come tornare indietro

Ogni modifica è reversibile senza reinstallare. Per riattivare le password SSH basta cancellare il file aggiunto e riavviare il servizio: sudo rm /etc/ssh/sshd_config.d/00-hardwarfare.conf, sudo sshd -t, sudo systemctl restart ssh.service. Il firewall si spegne con sudo ufw disable (le regole restano salvate). La swap si toglie con sudo swapoff /swapfile, cancellando la riga da /etc/fstab e poi il file. Se tutto il resto fallisce, lo snapshot fatto all’inizio riporta il VPS allo stato di partenza.

La nostra lettura

Questi otto passi non rendono un server inattaccabile, ma eliminano i due rischi più comuni: password indovinate da bot e servizi esposti per sbaglio. Il passo successivo è il rinforzo vero e proprio, con fail2ban e un controllo delle porte in ascolto, che trovate nella guida su https://hardwarfare.it/guide-tecniche/guide-server-self-hosting/proteggere-server-linux-ssh-fail2ban-ufw/. Da qui potete passare allo stack web con https://hardwarfare.it/ai-software/linux/installare-nginx-php-fpm-mariadb-ubuntu-lemp/ oppure ai container con https://hardwarfare.it/ai-software/linux/installare-docker-compose-ubuntu-debian/.

Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo