Abilitare SSH su Ubuntu: installare OpenSSH e proteggerlo

Abilitare SSH su Ubuntu: installare, avviare, aprire il firewall

SSH su Ubuntu arriva dal pacchetto openssh-server. Ubuntu Server propone di installarlo durante la configurazione e quasi ogni immagine cloud o VPS lo ha già in ascolto; Ubuntu Desktop non lo installa affatto.

1. Installare openssh-server

sudo apt update
sudo apt install -y openssh-server

Se il pacchetto è già presente, apt lo segnala e non cambia nulla. L'installazione registra anche un profilo applicativo UFW chiamato OpenSSH, usato al passo 3.

2. Abilitare e avviare il servizio

sudo systemctl enable --now ssh
systemctl status ssh

Su Ubuntu l'unità si chiama ssh; sshd è un alias. enable --now avvia il demone subito e a ogni avvio del sistema. Da Ubuntu 22.10 sshd è attivato via socket: ssh.socket possiede la porta 22 e avvia ssh.service alla prima connessione in ingresso, quindi uno stato inactive (dead) con TriggeredBy: ssh.socket subito dopo l'installazione è normale: la porta è aperta. Per un quadro più ampio, vedi come elencare i servizi con systemctl.

3. Consentire SSH attraverso UFW

Ubuntu distribuisce UFW disattivato. Se lo attivi, consenti SSH prima; abilitare il firewall prima che la regola esista è il modo classico di restare chiusi fuori da una macchina remota.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

ufw allow OpenSSH usa il profilo applicativo e apre la 22/tcp. Se in seguito sposti sshd, consenti la nuova porta con sudo ufw allow 2222/tcp ed elimina la vecchia regola. Trova l'indirizzo del server con hostname -I.

Connettersi da Windows, macOS o Linux

Ogni sistema operativo desktop attuale include un client OpenSSH e la sintassi è identica ovunque:

ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP      # non-default port

• Windows 10 e 11: apri PowerShell o Windows Terminal e digita il comando; il il client OpenSSH è incluso in Windows dal 2018 (versione 1809). Se ssh non viene riconosciuto, aggiungilo da Impostazioni > App > Funzionalità facoltative.
• macOS: Terminale, stesso comando.
• Linux: qualsiasi terminale; openssh-client è installato di default su Ubuntu.

Alla prima connessione, accetta l'impronta della chiave host del server con yes; viene salvata in ~/.ssh/known_hosts e riceverai un avviso se dovesse cambiare. Poi digita la password dell'account: la sezione successiva la sostituisce con una chiave.

Passare all'autenticazione a chiave

I login con password sono ciò che le botnet provano a forza bruta giorno e notte; le chiavi rendono inutili quei tentativi. Genera una coppia di chiavi Ed25519 sul tuo computer, mai sul server:

ssh-keygen -t ed25519 -C "laptop-2026"

Accetta il percorso predefinito (~/.ssh/id_ed25519) e imposta una passphrase; cifra la chiave privata su disco e con un agente SSH la digiti una sola volta per sessione. Solo il file .pub lascia la tua macchina.

Copiare la chiave pubblica sul server

Su macOS e Linux, ssh-copy-id lo fa in un passaggio, usando la password un'ultima volta:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IP

La build Windows di OpenSSH non include ssh-copy-id; invia invece la chiave da PowerShell tramite pipe:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Entrambi i metodi aggiungono la chiave al file ~/.ssh/authorized_keys di quell'utente. I permessi contano: sshd ignora silenziosamente il file se ~/.ssh non è in modalità 700 o se authorized_keys è scrivibile da qualcuno oltre al proprietario. Da un nuovo terminale, ssh username@SERVER_IP dovrebbe ora farti entrare senza la password dell'account. Non toccare la sezione successiva finché non funziona.

Irrobustire sshd_config: niente password, niente root, utenti in whitelist

Tieni aperta la sessione corrente mentre modifichi: se la nuova configurazione rompe qualcosa, è la tua via di ritorno. /etc/ssh/sshd_config inizia con Include /etc/ssh/sshd_config.d/*.conf, e sshd conserva il primo valore che legge per ogni parola chiave, quindi un drop-in prevale su qualsiasi cosa più in basso nel file principale. Inoltre le immagini cloud spesso includono /etc/ssh/sshd_config.d/50-cloud-init.conf con PasswordAuthentication yes, ed è per questo che modificare il file principale sembra così spesso non avere effetto. La soluzione è un drop-in il cui nome viene ordinato per primo:

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

Incolla quanto segue, sostituendo username con il tuo login:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

PermitRootLogin no presuppone che tu abbia un account non privilegiato con diritti sudo. Se finora hai lavorato come root, crea un utente sudo su Linux e copiaci la tua chiave prima di applicare il file. Poi valida la sintassi, ricarica e controlla i valori che sshd usa realmente una volta uniti tutti gli include: è ciò che stampa sshd -T:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'

Apri un secondo terminale ed entra con la tua chiave prima di chiudere il primo. Ecco cosa fa ogni direttiva:

Il keepalive ha anche un lato client: ServerAliveInterval 60 in ~/.ssh/config sulla tua macchina impedisce ai router NAT di chiudere le sessioni inattive.

Cambiare la porta SSH non è sicurezza

Spostare sshd dalla porta 22 è un consiglio molto diffuso. Ciò che ottieni sono meno righe di log. Gli scanner di massa passano in rassegna tutte le 65.535 porte e trovano sshd sulla 2222 nel giro di ore; chi prende di mira te lo trova in pochi secondi con nmap. Le chiavi, il divieto di login root, una whitelist e fail2ban sono la sicurezza; la porta è cosmetica. Aiuta comunque su un server trafficato mantenendo leggibile il log di autenticazione, ma non consideralo mai un livello di difesa.

Se decidi di cambiarla, rispetta questo ordine: apri la nuova porta in UFW, cambia la porta, riavvia, prova da un secondo terminale, poi rimuovi la vecchia regola. Togli il commento a #Port 22 in /etc/ssh/sshd_config, imposta la nuova porta, poi:

sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket    # Ubuntu 22.10 and later
sudo systemctl restart ssh           # Ubuntu 22.04 and earlier

Nelle release con attivazione via socket è l'unità socket, non sshd, a decidere quale porta viene aperta; Ubuntu include un generatore systemd che legge Port dalla configurazione di sshd durante daemon-reload e aggiorna ssh.socket. Verifica con sudo ss -tlnp | grep sshd: la guida su come controllare le porte aperte su Linux spiega l'output. Se sshd resta ostinatamente sulla 22, disattiva l'attivazione via socket e lascia che sia il servizio a occupare la porta: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. Una volta che ssh -p 2222 funziona da un terminale nuovo, esegui sudo ufw delete allow OpenSSH.

Aggiungere fail2ban e valutare l'autenticazione a due fattori

Con le password disattivate la forza bruta non può riuscire, ma ogni tentativo costa comunque un fork e una riga di log. fail2ban sorveglia il log di autenticazione e banna gli indirizzi che falliscono ripetutamente:

sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.local

Inserisci questo nel file:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Non modificare mai jail.conf; viene sostituito agli aggiornamenti e jail.local lo sovrascrive. port = ssh viene risolto tramite /etc/services, quindi scrivi port = 2222 se hai spostato il demone. backend = systemd legge direttamente il journal e funziona a prescindere dal fatto che la tua immagine scriva /var/log/auth.log. fail2ban-client status sshd elenca gli indirizzi bannati; sudo fail2ban-client set sshd unbanip 203.0.113.7 ne libera uno. Per impostazione predefinita le regole di fail2ban vengono valutate prima di quelle di UFW, quindi i due convivono.

Autenticazione a due fattori

Quando una chiave con passphrase non basta, libpam-google-authenticator aggiunge un codice temporaneo sopra la chiave: installalo, esegui google-authenticator come utente di login, aggiungi auth required pam_google_authenticator.so a /etc/pam.d/sshd (e commenta la riga @include common-auth), poi imposta KbdInteractiveAuthentication yes e AuthenticationMethods publickey,keyboard-interactive in sshd. Un guadagno reale contro un portatile rubato, e una cosa in più da perdere: tieni i codici di riserva fuori dal server.

Risoluzione dei problemi: connection refused, timed out, permission denied

Connection refused

Il server ha risposto ma nulla è in ascolto su quella porta: sshd è fermo, in ascolto altrove, oppure hai digitato la porta sbagliata. Dalla console del provider, esegui systemctl status ssh e sudo ss -tlnp | grep ssh. Un errore di sintassi impedisce del tutto l'avvio di sshd; sudo sshd -t stampa la riga incriminata e journalctl -u ssh -n 50 mostra l'ultimo avvio.

Connection timed out

I pacchetti vengono scartati, non rifiutati, il che quasi sempre significa un firewall: UFW senza la regola di allow (sudo ufw status verbose), un security group nel pannello del provider, o la tua rete che blocca la 22 in uscita: un hotspot da telefono lo esclude. ssh -v username@SERVER_IP mostra dove si blocca l'handshake.

Permission denied (publickey)

Il server è raggiungibile e ti sta rifiutando. Controlla, in ordine: il nome utente, se il file authorized_keys di quell'utente contiene la chiave che stai offrendo (ssh -i ~/.ssh/id_ed25519 -v forza una chiave specifica), i permessi su ~/.ssh e se il login manca da AllowUsers. Sul server, journalctl -u ssh -n 30 indica il motivo; Authentication refused: bad ownership or modes è il problema di permessi descritto sopra.

Avviso sulla chiave host

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED dopo una ricostruzione è atteso: esegui ssh-keygen -R SERVER_IP e riconnettiti. Se non hai reinstallato nulla, scopri il perché prima di digitare una password da qualche parte. Completamente chiuso fuori? La console del provider è la via di ritorno.

Tutto quanto sopra presuppone una macchina su cui hai i permessi di root e puoi permetterti di rompere sshd e ripararlo da una console. Un VPS Linux di rdp.monster è esattamente quella macchina: accesso root completo, CPU e RAM dedicate, banda illimitata (fair-use), nessun KYC, pagamento in cripto o in valuta tradizionale, da $8.99 al mese, e il server e online circa 10 secondi dopo la conferma del pagamento: tempo più che sufficiente per mettere le chiavi al loro posto prima che il primo scanner trovi la porta 22.

Domande frequenti

Ubuntu ha SSH abilitato per impostazione predefinita?

Ubuntu Desktop no; Ubuntu Server e la maggior parte delle immagini cloud sì.

Ubuntu Desktop installa solo il client SSH, quindi nulla è in ascolto sulla porta 22 finché non esegui sudo apt install openssh-server. Ubuntu Server chiede durante l'installazione se installare il server OpenSSH e può importare le tue chiavi GitHub o Launchpad nello stesso momento. Le immagini cloud e VPS includono quasi sempre openssh-server installato, abilitato e pronto ad accettare connessioni, perché è l'unico modo in cui il provider può consegnarti la macchina. Verifica con systemctl status ssh.

Come verifico se SSH è in esecuzione su Ubuntu?

Esegui systemctl status ssh, poi conferma con ss che la porta 22 sia in ascolto.

systemctl status ssh ti dice se il servizio è attivo o abilitato. Poiché Ubuntu 22.10 e successivi usano l'attivazione via socket, il servizio può legittimamente mostrare inactive (dead) con TriggeredBy: ssh.socket quando nessuno è connesso, quindi il test più affidabile è sudo ss -tlnp | grep ssh: una riga che mostra 0.0.0.0:22 o [::]:22 significa che SSH è in ascolto. Da un'altra macchina, ssh -v username@SERVER_IP lo conferma da un capo all altro.

È sicuro lasciare SSH sulla porta 22?

Sì, a patto che le password siano disattivate e si usino le chiavi; il numero di porta non aggiunge protezione.

La porta 22 attira continui tentativi di accesso automatizzati, ma quei tentativi non possono riuscire contro un server con PasswordAuthentication no e una coppia di chiavi, e fail2ban elimina gran parte del rumore. Spostare sshd sulla 2222 o sulla 22222 lo nasconde solo agli scanner più pigri; port scanner come nmap e masscan lo trovano in pochi minuti, e gli indici che scansionano tutta la rete lo elencano comunque. Considera una porta non standard come una misura di igiene dei log, non come un controllo di sicurezza, e non rinunciare mai alle chiavi perché hai cambiato porta.

Qual è la differenza tra ssh e sshd su Ubuntu?

ssh è il programma client; sshd è il demone server, la cui unità su Ubuntu si chiama ssh con sshd come alias.

ssh è il client che esegui sul tuo portatile per aprire una connessione; arriva dal pacchetto openssh-client. sshd è il demone che risponde sul server, dal pacchetto openssh-server, configurato in /etc/ssh/sshd_config (il client legge ssh_config). Ubuntu e Debian chiamano l'unità systemd ssh.service e dichiarano sshd.service come alias, quindi systemctl restart ssh e systemctl restart sshd fanno la stessa cosa; su Fedora, RHEL e Arch l'unità si chiama semplicemente sshd.