Ubuntu 22.04 Server / Accedere come root in locale e tramite SSH
Su Ubuntu 22.04 Server, il modo abituale di lavorare con privilegi root è accedere con un account normale ed eseguire sudo -i. L’accesso diretto come root richiede di verificare separatamente password e politica di accesso; SSH dipende anche da PermitRootLogin e dai metodi di autenticazione.
Privilegi root e accesso diretto
Root è l’account che amministra l’intero sistema. Ubuntu ne blocca la password per impostazione predefinita e consente agli utenti autorizzati di usare sudo con le proprie credenziali. L’account root esiste comunque. Questo modello è descritto nella documentazione Ubuntu sulla gestione degli utenti.
Se serve soltanto una shell amministrativa, usa i comandi seguenti. L’autenticazione normalmente impiega la password dell’account normale, secondo la politica sudo. Verifica che whoami mostri root e, al termine, torna all’account normale con exit. Questo non attiva la password root e non modifica SSH.
sudo -i
whoami
exit
Imposta separatamente una password root solo se serve un accesso con password dalla console o un passaggio tramite su -. La prima richiesta sudo riguarda l’account normale; le due successive impostano la nuova password root. I caratteri digitati non vengono mostrati.
sudo passwd root
su -
whoami
exit
su - usa la password root appena impostata. Definirla non autorizza automaticamente ogni accesso: PAM (Pluggable Authentication Modules, moduli di autenticazione collegabili) e le politiche di console o accesso remoto possono limitarlo. Il manuale sudo di Ubuntu 22.04 spiega sudo -i.
Controllare accesso e politica SSH esistente
La procedura riguarda OpenSSH su un server Ubuntu 22.04 che amministri. Mantieni aperta la sessione SSH dell’account normale e prepara una console fisica o di recupero cloud. In produzione considera prima un account normale seguito da sudo. Se occorre root diretto, definisci anche chiavi pubbliche e rete di amministrazione consentita.
Se manca il server SSH, esegui sudo apt update e poi sudo apt install openssh-server. Controlla il servizio con sudo systemctl status ssh.service. Servono indirizzo e porta effettivi; firewall e regole cloud devono consentire quel percorso amministrativo.
Salva la configurazione e individua le direttive prima di modificarle. Se il nome del backup esiste già, scegline un altro per non sovrascriverlo. Conserva le copie fuori dalle directory caricate tramite *.conf, come nell’esempio.
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-root-login
sudo cp -a /etc/ssh/sshd_config.d /etc/ssh/sshd_config.d.before-root-login
sudo grep -RnsE '^[[:space:]]*(Include|Match|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthenticationMethods|AllowUsers|DenyUsers|AllowGroups|DenyGroups)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d
Il file del server è sshd_config, diverso da ssh_config del client. Ubuntu 22.04 normalmente carica prima /etc/ssh/sshd_config.d/*.conf. Molte direttive usano il primo valore ottenuto, quindi una riga aggiunta in fondo potrebbe non sostituire quella precedente. Esamina l’ordine Include, le condizioni Match e i file generati dal cloud, poi verifica i valori effettivi.
Nel manuale sshd_config di Ubuntu 22.04, PermitRootLogin yes permette root quando sono soddisfatte le altre condizioni. prohibit-password impedisce password e autenticazione interattiva da tastiera per root, ma può consentire chiavi pubbliche. no vieta root via SSH. Una riga predefinita commentata non basta a stabilire la politica reale.
Configurare SSH root con password
Questo metodo espone l’autenticazione della password root: sceglilo solo quando il contesto amministrativo lo richiede. Imposta la password con sudo passwd root, poi modifica la configurazione realmente prioritaria con sudoedit /etc/ssh/sshd_config o il frammento pertinente. Quello seguente è un esempio di politica, non un invito ad aggiungere righe alla cieca in fondo.
PermitRootLogin yes
PasswordAuthentication yes
PermitRootLogin yes non basta. Devono consentire l’accesso anche autenticazione con password, AuthenticationMethods, restrizioni di utenti o gruppi, PAM e stato dell’account. Un PasswordAuthentication yes globale può coinvolgere altri utenti: controlla se amplia la politica. Non disabilitare firewall o autenticazione multifattore per seguire questa guida.
Salvare il file non completa l’applicazione. Esegui prima la verifica e il ricaricamento descritti sotto, poi prova dal client. Sostituisci 192.0.2.20 con l’indirizzo reale. Per una porta diversa dalla predefinita 22, usa ssh -p PORT con il numero effettivo.
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@192.0.2.20
Il test sceglie la password al posto della chiave pubblica. La sola password non funziona se il server richiede altra autenticazione. Controlla l’impronta della chiave host tramite un canale amministrativo affidabile; non disattivare la verifica per aggirare un avviso di chiave cambiata.
Usare una chiave pubblica per SSH root
Il client conserva la chiave privata e sul server viene registrata solo la pubblica corrispondente. Attivare la password root non è un prerequisito. Puoi installare la chiave da una sessione amministrativa esistente o dalla console, senza aprire prima SSH root con password.
Se il client non ha una chiave adatta, generala con ssh-keygen -t ed25519. Scegli un nome nuovo senza sovrascrivere chiavi esistenti e proteggi la privata con una passphrase. Registra la singola riga di ~/.ssh/id_ed25519.pub. Non copiare mai sul server la chiave privata senza suffisso .pub.
Nella sessione amministrativa già aperta sul server, prepara i permessi come sotto e aggiungi nell’editor la riga della chiave pubblica del client. Conserva le chiavi esistenti ed evita duplicati. Se hai scelto un altro nome di file, usa la pubblica corrispondente.
sudo install -d -m 700 -o root -g root /root/.ssh
sudo touch /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudoedit /root/.ssh/authorized_keys
L’esempio usa il percorso predefinito delle chiavi autorizzate. Controlla il percorso effettivo se AuthorizedKeysFile ne indica un altro. Scegli la politica seguente per impedire la password root, correggi le direttive precedenti in conflitto e verifica.
PermitRootLogin prohibit-password
PubkeyAuthentication yes
Dopo verifica e applicazione sul server, connettiti dal client come segue. Se viene richiesta la passphrase della chiave privata, usa quella della chiave client, non la password root. Anche le chiavi pubbliche devono soddisfare politiche PAM, di account e di accesso.
ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@192.0.2.20
Verificare la configurazione e provare una nuova sessione
- Controlla prima sintassi e chiavi host sul server. Un test
-triuscito normalmente non produce output. Se ci sono errori, correggi file e riga prima di ricaricare.-Tmostra la configurazione effettiva; con-C, valuta le condizioni Match della connessione indicata.
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=root,addr=192.0.2.10,host=admin.example | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods|authorizedkeysfile|allowusers|denyusers|allowgroups|denygroups) '
Sostituisci 192.0.2.10 con l’indirizzo del client amministrativo visto dal server e admin.example con il nome host client da valutare. Con Match LocalAddress o LocalPort, aggiungi anche laddr e lport a -C. Se l’output è inatteso, indaga prima priorità e condizioni. Le opzioni sono spiegate nel manuale sshd di Ubuntu 22.04.
- Quando sintassi e valori effettivi corrispondono alla politica voluta, ricarica il servizio. Mantieni aperta la sessione amministrativa e prova password o chiave in un’altra finestra client.
sudo systemctl reload ssh.service
sudo systemctl is-active ssh.service
- Un servizio
activenon garantisce una nuova autenticazione riuscita. Nella nuova sessione root, controlla chewhoamimostrirooteid -umostri0. Prova anche un nuovo accesso normale e sudo. Condizioni di utente, chiave, rete e account possono ancora negare l’accesso.
Diagnosticare gli errori e annullare l’accesso root diretto
Per Permission denied, controlla autenticazione, account e politica di accesso. Per timeout o connessione rifiutata, esamina separatamente indirizzo, porta, servizio e firewall. Usa sudo journalctl -u ssh.service -n 50 --no-pager sul server e ssh -v root@192.0.2.20 sul client. Nascondi indirizzi, nomi utente e altri dati sensibili prima di condividere i log.
Per vietare di nuovo root via SSH, imposta il PermitRootLogin effettivo su no, verifica sshd -t e sshd -T con le condizioni di connessione, poi esegui sudo systemctl reload ssh.service. Ripristina anche la politica di password cambiata temporaneamente. Annulla solo le modifiche ai file e alle voci interessate, senza sovrascrivere tutta la directory dei frammenti.
Dopo aver confermato SSH e sudo con un altro account normale, blocca la password root se l’hai attivata per questa attività e non serve più. Secondo il manuale passwd, -l blocca la password, non ogni accesso, come le chiavi pubbliche. Verifica separatamente il divieto SSH con PermitRootLogin no.
sudo passwd -l root
Bloccare la password o modificare SSH non termina automaticamente le sessioni root esistenti. Completa il lavoro e chiudi le shell root aperte con exit. Se serve recuperare l’accesso, usa la sessione normale mantenuta aperta o la console di recupero, basandoti sui backup e sul registro delle modifiche.



