Ubuntu / Porta SSH, accesso root e gestione della rete con NetworkManager

Prima di cambiare la porta SSH o l’autenticazione su Ubuntu, verifica la configurazione effettiva del servizio e del socket. Questi appunti spiegano il cambio di porta, l’accesso diretto a root come eccezione e le condizioni per usare nmtui. Mantieni disponibili un normale account amministrativo, l’accesso con chiave pubblica e una console di ripristino.

Per preparare le chiavi e verificare un nuovo accesso, consulta la guida alla configurazione di OpenSSH e alla prova dell’autenticazione con chiave pubblica, disponibile in inglese.

Verificare la configurazione attiva prima di modificarla

SSH (Secure Shell) consente l’accesso remoto cifrato. Su Ubuntu la porta può essere gestita direttamente dal demone sshd oppure da un socket systemd che attiva il servizio quando necessario. Leggi prima lo stato delle unità, le porte effettivamente in ascolto e le impostazioni interpretate da sshd.

cat /etc/os-release
systemctl status ssh.socket ssh.service --no-pager
sudo ss -lntp
sudo sshd -T | grep -E "^(port|listenaddress|permitrootlogin|passwordauthentication|authenticationmethods) "

Lascia aperta la connessione SSH corrente e verifica di poter aprire la console del server. Salva una copia di /etc/ssh/sshd_config e dei file inclusi prima di modificarli. Per molte opzioni OpenSSH usa il primo valore ottenuto: aggiungere una riga in fondo non garantisce che prevalga sulle precedenti.

Se sono presenti regole Match, esamina anche sshd -T -C con utente e indirizzi reali della connessione. L’opzione -T mostra la configurazione effettiva; -C fornisce le condizioni con cui valutare Match. Non confondere l’output di configurazione con la prova di un accesso riuscito. La documentazione ufficiale di sshd descrive i parametri di verifica.

Lo stato non attivo di una delle due unità non dimostra, da solo, un guasto: va interpretato in base alla modalità usata dal server. Cambiare porta non sostituisce l’autenticazione robusta o le limitazioni di accesso dalla rete.

Esempio: spostare SSH sulla porta 1980

1980 è una porta di esempio. Scegline una libera e autorizza prima il nuovo collegamento dalla sorgente amministrativa sui firewall effettivamente attivi, sia del server sia del provider. Se usi UFW, sostituisci 192.0.2.10, indirizzo riservato alla documentazione, con l’indirizzo reale da cui amministri il server. La guida alle restrizioni dei client e delle porte con UFW è disponibile in inglese.

sudo ufw allow from 192.0.2.10 to any port 1980 proto tcp

Modifica Port nella configurazione SSH realmente applicata. Controlla gli Include e la struttura Match, evitando valori concorrenti aggiunti senza esaminare quelli esistenti. La riga seguente è una direttiva di configurazione, non un comando da eseguire nella shell.

Port 1980

Verifica la sintassi prima di applicare la modifica. In caso di errore, correggilo senza riavviare il servizio.

sudo sshd -t

Se ssh.socket è attivo, riavviare soltanto il servizio può lasciare invariata la porta in ascolto. In Ubuntu 24.04 e versioni successive controlla anche le impostazioni generate dal pacchetto per il socket. Puoi esaminare le unità e i drop-in caricati con systemctl cat ssh.socket. Un drop-in è un frammento di configurazione che integra o modifica un’unità systemd. La nota del team Ubuntu sull’attivazione SSH tramite socket spiega il passaggio al generatore per porte e indirizzi.

Solo se serve un override esplicito, usa sudo systemctl edit ssh.socket per il frammento seguente. La riga vuota ListenStream= azzera l’elenco precedente. Se esiste un binding limitato a un indirizzo specifico, preservalo: sostituirlo con il solo numero di porta può ampliare gli indirizzi di ascolto. Non cancellare altri override già necessari.

[Socket]
ListenStream=
ListenStream=1980

Applica i comandi seguenti soltanto dopo aver confermato la modalità basata su socket. Se il sistema usa soltanto il servizio, non attivare un nuovo socket: dopo la validazione ricarica o riavvia ssh.service secondo la configurazione in uso.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket ssh.service
sudo ss -lntp

Da un client separato prova ssh -p 1980 user@server, sostituendo utente e server con quelli reali. Verifica la porta in ascolto, il nuovo login e l’esecuzione di sudo dal normale account amministrativo. Mantieni la regola della vecchia porta e la sessione corrente finché le verifiche non sono concluse; elimina poi soltanto le autorizzazioni diventate superflue secondo la politica prevista.

Se la prova fallisce, usa la console per ripristinare dalle copie soltanto le impostazioni SSH e l’override del socket modificati in questa operazione. Valida la configurazione, applicala e recupera prima l’accesso sulla porta originale. La guida ufficiale Ubuntu a OpenSSH descrive file di configurazione e controlli.

Limitare l’accesso diretto a root ai casi eccezionali

Usa come percorso amministrativo principale un normale account con sudo. Se l’accesso diretto a root è necessario, prepara una chiave pubblica e verifica la politica effettivamente applicata a root. Le tre righe seguenti sono un frammento da collocare nel contesto delle regole esistenti, non un invito a sostituire globalmente l’autenticazione dell’organizzazione.

PermitRootLogin prohibit-password
PubkeyAuthentication yes
AuthenticationMethods publickey

Per limitarle a root, inseriscile nel blocco Match User root appropriato della configurazione esistente, preservando le regole e i metodi di autenticazione degli altri amministratori. Controlla i confini dei blocchi e i file inclusi prima di salvare. prohibit-password disabilita per root password e autenticazione keyboard-interactive, ma da solo non esclude ogni altro metodo diverso dalla chiave pubblica. Se è richiesta esclusivamente la chiave, verifica anche AuthenticationMethods.

Stato dell’account, permessi dei file delle chiavi e regole PAM (Pluggable Authentication Modules) possono imporre altre restrizioni. PermitRootLogin yes non garantisce da solo l’accesso con password: contano anche le opzioni di autenticazione, il blocco dell’account e PAM. Non abilitare la password di root come rimedio ordinario a un problema di accesso.

Verifica sshd -t, sshd -T -C con le condizioni reali e una nuova connessione con chiave. Controlla separatamente che sudo funzioni ancora dall’account amministrativo normale. Quando l’eccezione non serve più, ripristina PermitRootLogin no e verifica nuovamente la configurazione. Il manuale ufficiale sshd_config descrive precedenze, Match e metodi di autenticazione.

Identificare il gestore di rete prima di usare nmtui

systemctl is-active NetworkManager systemd-networkd
sudo netplan get
command -v nmtui

nmtui modifica i profili di connessione di NetworkManager attraverso un’interfaccia testuale. Se serve, verifica che il pacchetto network-manager della distribuzione fornisca lo strumento; la sua installazione non migra automaticamente e senza rischi una rete già gestita da Netplan e systemd-networkd.

Netplan descrive la rete e il renderer indica il backend che la gestisce, per esempio NetworkManager o systemd-networkd. Leggi lo stato di ciascuno e la configurazione effettiva dell’interfaccia; un gestore inattivo può essere normale se è in uso l’altro. Evita che due gestori controllino la stessa interfaccia. Prima di cambiare un server remoto, decidi il gestore corretto e prepara una console con cui ripristinare l’accesso.

La guida per distinguere Netplan, NetworkManager e networkd, in inglese, approfondisce le responsabilità dei componenti. Consulta anche il manuale ufficiale nmtui e la documentazione Netplan sul renderer per i rispettivi ambiti.