Come abilitare SSH su Debian 12: guida per server e desktop

Su Debian 12 abilitare SSH significa prima di tutto decidere perché ti serve: accesso amministrativo a un server headless, manutenzione di una macchina desktop, tunnel sicuro per servizi interni o gestione remota da una rete non fidata. La procedura base è semplice, ma il punto vero non è installare il demone: è farlo partire, verificarlo, limitarne l’esposizione e lasciare un percorso di recupero se qualcosa va storto.

Su un server Debian 12 l’implementazione standard è OpenSSH Server. Sul desktop la logica è identica, ma cambia il rischio operativo: su un PC con sessione grafica e firewall più permissivo è facile esporre più di quanto serva. Per questo conviene partire con un approccio minimale: installi il servizio, controlli lo stato, provi una connessione locale o da una macchina fidata, poi restringi l’accesso con chiavi, porte e regole di rete.

Pacchetto giusto e servizio da verificare subito

Su Debian 12 il pacchetto da installare è openssh-server. Se hai solo il client, puoi connetterti in uscita ma non accettare connessioni in ingresso. Dopo l’installazione, il servizio da osservare è ssh gestito da systemd.

La sequenza minima è questa:

sudo apt update
sudo apt install openssh-server
systemctl status ssh --no-pager

Se il servizio è attivo, nello stato devi vedere active (running). Se invece è inactive o failed, il primo file da consultare è il journal del servizio, non la configurazione alla cieca:

journalctl -u ssh -b --no-pager

Un errore comune è confondere il nome del pacchetto con quello del servizio. Il pacchetto è openssh-server, il servizio systemd è ssh. Se cerchi sshd nei comandi systemd su Debian spesso non trovi il target che ti aspetti.

Abilitazione immediata: avvio, auto-start e controllo porta

Dopo l’installazione, il demone dovrebbe essere avviato e abilitato al boot. Se non lo è, il fix minimo è reversibile e non tocca dati:

sudo systemctl enable --now ssh
sudo systemctl is-enabled ssh
sudo systemctl is-active ssh
ss -tlnp | grep ':22'

Il comando ss -tlnp ti dice se il processo sta ascoltando sulla porta 22. L’atteso è una riga con LISTEN e sshd. Se non compare nulla, il problema è prima del firewall: servizio non partito, bind fallito, configurazione errata o porta cambiata.

Se vuoi un check rapido dall’esterno, usa una verifica TCP semplice o una sessione SSH verbosa. Il secondo metodo è più utile perché mostra la fase esatta del fallimento:

ssh -vvv user@IP_DEL_SERVER

Con -vvv vedi se il problema è risoluzione DNS, handshake, autenticazione o chiusura da parte del server. Se la connessione cade prima del prompt di password o chiave, non stare a guardare solo la configurazione di autenticazione: controlla prima rete, porta e firewall.

Firewall: aprire SSH senza allargare troppo la superficie

Su Debian puoi usare nftables, ufw o regole gestite dal pannello del provider. La regola di base è sempre la stessa: consenti la porta SSH solo da dove serve davvero. Se sei in fase di recupero e lavori da remoto, aprire temporaneamente la porta verso il tuo IP è più prudente che lasciare un accesso mondiale senza limiti.

Con ufw il percorso è diretto:

sudo ufw allow OpenSSH
sudo ufw status verbose

Se usi nftables, verifica la chain attiva prima di aggiungere eccezioni. Non inventare regole in un file a caso: controlla la configurazione realmente caricata.

sudo nft list ruleset

Se la porta 22 risponde in locale ma non da fuori, il firewall è uno dei primi sospetti. Se invece non risponde nemmeno in locale, il firewall non è il primo posto dove guardare.

Accesso con chiavi: il modo corretto di usare SSH su Debian 12

La password va bene per un test iniziale, ma in produzione la base sensata è la coppia di chiavi. Il flusso tipico è: generi una chiave sul client, copi la chiave pubblica sul server, verifichi l’accesso e solo dopo eventuali disattivazioni della password. Non fare il contrario.

ssh-keygen -t ed25519 -a 100
ssh-copy-id user@IP_DEL_SERVER
ssh user@IP_DEL_SERVER

Una chiave ed25519 è in genere la scelta pratica migliore: più leggera di RSA, più moderna, più semplice da gestire. Il parametro -a 100 aumenta il costo KDF della chiave privata e rende un po’ più oneroso l’attacco offline in caso di furto del file locale.

Il file lato server è ~/.ssh/authorized_keys dell’utente di destinazione. I permessi devono essere coerenti, altrimenti OpenSSH ignora la chiave. Se la chiave non funziona, il problema spesso non è la chiave ma il contesto: ownership, permessi, home directory scrivibile da altri o path sbagliato.

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

L’atteso è che la home non sia scrivibile da altri e che .ssh e authorized_keys siano del giusto utente. Se hai dubbi, correggi con cautela e poi ritesta la sessione. Il comando seguente è innocuo e spesso risolve i casi banali:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Hardening minimo: togliere i rischi più comuni senza bloccarti fuori

La parte delicata non è accendere SSH, ma ridurre il rischio senza rompere l’accesso. Il principio corretto è semplice: prima verifichi che entri con chiave da una seconda sessione, poi modifichi la configurazione. Se fai hardening prima del test, stai creando un possibile lockout.

Il file di riferimento è /etc/ssh/sshd_config. Su Debian 12 conviene lavorare con un override ben leggibile e fare sempre backup prima di toccarlo:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)

Le opzioni più utili, in un ambiente normale, sono queste:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
X11Forwarding no

PermitRootLogin no riduce il valore di un eventuale furto di credenziali. PasswordAuthentication no elimina il login via password una volta che le chiavi sono verificate. MaxAuthTries 3 abbassa il rumore da brute force. X11Forwarding no toglie una funzione spesso inutile sui server.

Dopo ogni modifica, non riavviare a occhi chiusi. Prima fai il test di sintassi con il binario del demone:

sudo sshd -t

Se il comando non produce output, la sintassi è accettata. Se segnala errori, correggi prima di ricaricare il servizio. Questo è il punto dove si evitano molti lockout inutili.

Quando la sintassi è corretta, ricarica il servizio senza interrompere brutalmente le sessioni già aperte:

sudo systemctl reload ssh

Se il tuo ambiente usa una versione di OpenSSH con file di drop-in in /etc/ssh/sshd_config.d/, è spesso più pulito inserire le personalizzazioni lì invece di sporcare il file principale. Il vantaggio è operativo: separi il pacchetto base dalle tue policy locali e riduci il rischio di conflitti durante gli aggiornamenti.

Desktop Debian 12: SSH sì, ma con criteri diversi dal server

Su un desktop non serve per forza lasciare SSH sempre esposto sulla rete. Se devi amministrare la macchina da remoto solo in alcune finestre temporali, puoi tenere il servizio installato ma controllare l’esposizione tramite firewall o avvio manuale. In pratica: il demone può esistere, ma non deve per forza essere raggiungibile da ovunque.

Se usi il desktop in LAN, una regola sensata è limitare l’accesso alla subnet interna. Se sei fuori sede, meglio un accesso da VPN o da IP noto. Aprire SSH su una macchina personale direttamente su Internet è quasi sempre una scelta peggiore di quanto sembri, soprattutto se il sistema ospita anche browser, mail e file personali.

Per verificare se il desktop accetta connessioni, controlla prima il servizio e poi la porta:

systemctl status ssh --no-pager
ss -tlnp | grep sshd

Se il desktop è in ambiente grafico ma non risponde via SSH, non dare per scontato che il problema sia la GUI. Spesso il servizio non è installato, il firewall è attivo oppure la macchina è dietro NAT senza port forwarding. Qui il layer da verificare è molto banale: rete prima dell’applicazione.

Debug rapido: distinguere errore di rete, autenticazione e configurazione

Quando SSH non funziona, la diagnosi veloce va fatta in ordine. Prima capisci se il server raggiunge la porta, poi se il demone risponde, poi se l’autenticazione è accettata. Mescolare tutto insieme porta a tentativi inutili.

1. Rete/porta: nc -vz IP_DEL_SERVER 22 oppure ssh -vvv user@IP_DEL_SERVER. Se la porta è chiusa o filtrata, non ha senso guardare le chiavi.

2. Servizio: systemctl status ssh e journalctl -u ssh -b. Se il demone è crashato o non parte, la porta non si aprirà mai.

3. Autenticazione: se arrivi al server ma vieni respinto, controlla ~/.ssh/authorized_keys, permessi e policy in /etc/ssh/sshd_config.

Un dettaglio utile: lato client, ssh -vvv mostra anche quale chiave sta provando. Se hai più chiavi caricate nell’agent, puoi perdere tempo dietro a una chiave sbagliata. In quel caso, forza temporaneamente quella giusta:

ssh -i ~/.ssh/id_ed25519 user@IP_DEL_SERVER

Se il login funziona con -i ma non senza, il problema è il selection layer del client, non il server. È un classico caso in cui il server è sano e il sintomo sembra altrove.

Recupero da lockout: come rientrare senza peggiorare la situazione

Il rischio più concreto quando abiliti SSH è bloccarti fuori dopo una modifica a sshd_config. Il recupero dipende dal tipo di accesso che hai ancora. Se hai console locale, IPMI, KVM, console del provider o accesso fisico, puoi correggere il file direttamente. Se non hai nessun canale alternativo, il problema non è tecnico ma operativo: stai facendo change senza rollback.

La strategia corretta è questa: tieni sempre una sessione SSH aperta mentre fai il test di una seconda sessione, e non chiudere la prima finché la nuova non è confermata. In pratica il rollback è già pronto: ripristini il backup e ricarichi il servizio.

sudo cp /etc/ssh/sshd_config.bak.YYYY-MM-DD-HHMM /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload ssh

Se hai creato un lockout disattivando l’autenticazione via password prima di testare la chiave, il ripristino più rapido è rimettere temporaneamente la password, ricaricare il servizio e poi correggere la chiave con calma. Non è elegante, ma è meglio di restare fuori dalla macchina.

Versione pratica per server esposto e macchina interna

Su un server esposto su Internet il set minimo sensato è: chiavi, root disabilitato, password disabilitata dopo test, firewall stretto, aggiornamenti regolari. Su una macchina interna o di laboratorio puoi essere più permissivo, ma solo se sai perché. La differenza non è estetica: cambia il profilo di rischio.

Una configurazione di buon senso, da adattare al contesto, è questa:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers tuo_utente

AllowUsers è utile quando vuoi ridurre i tentativi sui soli account autorizzati. Non sostituisce il firewall, ma riduce la superficie logica del servizio. Se la macchina è condivisa o gestita da più persone, meglio ragionare anche su gruppi o bastion host invece di aprire tutto al mondo.

Cosa controllare dopo l’abilitazione

Dopo aver abilitato SSH, il controllo finale non è solo “riesco a entrare”. Devi verificare quattro cose: che il servizio parta al boot, che la porta sia raggiungibile, che l’accesso sia limitato come previsto e che i log non mostrino errori ricorrenti.

1. systemctl is-enabled ssh deve restituire enabled se vuoi persistenza al riavvio.

2. ss -tlnp | grep ':22' deve mostrare il listener del demone.

3. ssh user@server deve funzionare con la chiave prevista, senza password se l’hai disabilitata.

4. journalctl -u ssh -b non deve mostrare errori di permessi, chiavi rifiutate o configurazione invalida.

Se vuoi fare una verifica più concreta del comportamento reale, effettua un login da un host diverso dalla macchina stessa. Il test in locale può mentire: la rete interna, il NAT o il firewall possono nascondere il problema reale fino al primo accesso remoto.

Checklist finale da usare senza pensarci troppo

Se devi portare su SSH su Debian 12 in modo pulito, questa è la sequenza che evita gli errori più comuni:

1. Installa openssh-server.

2. Controlla systemctl status ssh e ss -tlnp.

3. Apri il firewall solo quanto serve.

4. Configura e testa le chiavi prima di togliere la password.

5. Valida la sintassi con sshd -t prima del reload.

6. Tieni un canale di accesso alternativo per il rollback.

Se fai queste sei cose nell’ordine giusto, SSH su Debian 12 non è un problema. Diventa un servizio normale, osservabile e gestibile, che puoi mantenere sia su server sia su desktop senza improvvisare. Assunzione: ambiente Debian 12 standard con OpenSSH dai repository ufficiali e accesso amministrativo locale o alternativo per il primo setup.