Creare un utente sudo non-root su un VPS e perché il login root è rischioso

Accedere come root è un po' come muoversi con un passe-partout: è un metodo rapido e potente, ma basta un singolo errore per fare danni irreparabili.

In breve: per creare un utente non-root con privilegi sudo, occorre prima creare un account utente standard, fornirgli l'autorizzazione per eseguire attività amministrative tramite sudo, verificare che l'accesso funzioni e, soltanto alla fine, limitare o disabilitare l'accesso diretto come root. Questo approccio rende la gestione quotidiana del server molto più sicura: i comandi ordinari vengono eseguiti con permessi limitati, mentre le facoltà amministrative vengono richiamate solo quando strettamente necessario.

Cos’è un utente non-root con privilegi sudo?

Su un server Linux, root è l'account amministrativo supremo. Può modificare file di sistema, rimuovere applicazioni, alterare le impostazioni di sicurezza ed eliminare intere directory senza mai chiedere conferma.

Un utente non-root, al contrario, è un account standard con permessi circoscritti. Può essere paragonato a un badge aziendale standard anziché al passe-partout dell'edificio: permette di accedere unicamente ai locali necessari, evitando di sbloccare o compromettere inavvertitamente l'intera struttura ad ogni movimento.

L'acronimo sudo sta per superuser do. Questo comando consente a un utente standard autorizzato di eseguire un singolo comando con i privilegi di amministratore. Anziché operare costantemente come root, si attivano i poteri amministrativi solo per la singola operazione richiesta, per poi tornare immediatamente al profilo standard.

Questa breve pausa riflessiva è fondamentale: ogni volta che si digita sudo, si compie un'azione consapevole, ricordando a se stessi che il comando in esecuzione modificherà il sistema.

Perché l'accesso diretto come root è rischioso?

Accedere direttamente come root è pericoloso perché ogni singolo comando viene eseguito con la massima autorità. Non esiste alcuna barriera di protezione tra un semplice errore di battitura e una modifica irreversibile al sistema.

Durante una sessione root, un errore di digitazione in un comando di eliminazione, una configurazione errata dei permessi di un file o un codice copiato da un tutorial datato possono compromettere seriamente l'intero server. È come cucinare tenendo la fiamma al massimo: può anche funzionare, ma non concede il minimo margine di disattenzione.

Inoltre, root rappresenta il bersaglio primario per gli attacchi informatici. I malintenzionati sanno bene che l'account root esiste su gran parte dei server Linux e concentrano i loro tentativi automatici per violarne le credenziali o sfruttarne le vulnerabilità. Creare un utente dedicato con permessi sudo non elimina qualsiasi rischio, ma chiude la porta d'accesso più evidente ed esposta.

Per questa ragione, la creazione di un utente sudo rappresenta uno dei pilastri fondamentali della messa in sicurezza iniziale, al pari di un firewall. A questo proposito, una volta completata la gestione degli accessi, ti consigliamo di consultare la nostra guida su come configurare un firewall sul server.

Come creare un utente sudo in tutta sicurezza?

La procedura consigliata è lineare: si crea il nuovo utente, gli si assegnano i privilegi sudo, si verifica il funzionamento dell'accesso e, solo al termine, si limita l’accesso diretto dell'utente root.

Sui principali sistemi Ubuntu o Debian, il procedimento è il seguente:

bashadduser sam
usermod -aG sudo sam

È sufficiente sostituire sam con il nome utente desiderato. Il primo comando crea il nuovo account; il secondo lo aggiunge al gruppo sudo, ovvero la lista degli utenti autorizzati a eseguire comandi con i privilegi di sistema.

Successivamente, occorre verificare che il nuovo utente riesca ad autenticarsi correttamente. Se si utilizzano chiavi SSH, è necessario copiare la chiave pubblica all'interno del profilo del nuovo utente. Importante: non chiudere la sessione root corrente! Apri una seconda finestra del terminale e verifica le nuove credenziali.

Una volta effettuato l'accesso, prova ad eseguire un comando amministrativo non invasivo tramite sudo (ad esempio, il controllo degli aggiornamenti di sistema). Se il sistema richiede la password dell'utente ed esegue il comando senza errori, l'accesso sudo è configurato correttamente.

Soltanto a questo punto è opportuno disabilitare il login diretto come root via SSH. La tempistica è cruciale: se si disattiva l'accesso root prima di aver verificato le nuove credenziali, si rischia di rimanere bloccati fuori dal server, trasformando un'operazione da cinque minuti in un ripristino di emergenza.

Cosa può andare storto con una gestione errata dei permessi?

L'errore più frequente è il messaggio: sudo: user is not in the sudoers file. Questo indica che l'utente è stato creato, ma non è stato abilitato ad eseguire operazioni amministrative. Per risolverlo, occorre associare l'utente al gruppo con i permessi sudo o aggiungere una regola specifica nel file sudoers, operando da un account amministrativo già attivo.

Un'altra anomalia diffusa è l'errore Permission denied (publickey). Generalmente segnala che il server non ha riscontrato una chiave SSH valida abbinata al profilo in uso. L'account potrebbe essere corretto, ma la chiave potrebbe trovarsi in un percorso errato, avere permessi/proprietario non validi o appartenere a un altro utente.

Inoltre, occorre prestare attenzione alla titolarità (ownership) dei file. Se i file di un'applicazione vengono creati da root e successivamente l'applicazione viene eseguita con un utente standard, quest'ultimo potrebbe non avere i permessi per scrivere i log, caricare file o completare gli aggiornamenti. L'applicazione sembrerà malfunzionante, ma la causa risiede semplicemente in un conflitto di proprietà dei file.

In caso di problemi con gli accessi, la consultazione dei log del sistema offre solitamente la chiave di svolta. Se vuoi approfondire questo argomento, puoi consultare questa guida alla lettura dei log del server per imparare a distinguere i problemi di autenticazione da quelli legati alle applicazioni.

FAQ

L'account root serve ancora? Sì, ma in linea generale non è necessario effettuare il login diretto come root. I privilegi amministrativi rimangono accessibili tramite il comando sudo eseguito da un utente autorizzato.

Ogni progetto dovrebbe utilizzare un utente dedicato? Nella maggior parte dei casi sì. Utilizzare utenti distinti previene il rischio che un'applicazione vada a modificare o sovrascrivere accidentalmente i file di un altro progetto.

**sudo è davvero più sicuro dell'accesso come root?** Sì, perché nell'operatività quotidiana limita l'uso dei privilegi amministrativi a operazioni temporanee e mirate. Pur non essendo una soluzione infallibile, riduce drasticamente i danni dovuti a sviste o errori accidentali.

**Si può disabilitare subito il login diretto come root?** No, mai farlo prima di aver testato il nuovo utente con permessi sudo in una sessione SSH parallela, altrimenti si corre il rischio concreto di rimanere chiusi fuori dal server.

La scorciatoia

Server Manager semplifica l'intera gestione rendendo sempre visibile la configurazione degli accessi, evitando di dover fare affidamento sulla memoria o su appunti sparsi. In questo modo è possibile verificare immediatamente quale utente gestisce il server e l'allocazione dei vari progetti, prevenendo le classiche sovrapposizioni in cui root risulta proprietario di risorse necessarie all'applicazione.

Questo evita il sorgere di problematiche insidiose a distanza di tempo, come applicazioni che non riescono a registrare i log, procedure di deploy bloccate dai permessi o configurazioni dimenticate. Il beneficio principale non risiede nello saltare le nozioni tecniche, ma nel mantenere la struttura del server chiara e ordinata anche dopo la fase iniziale.

Un'organizzazione trasparente si rivela preziosa quando si torna sul server a distanza di mesi per aggiornare un'applicazione, effettuare un ripristino o trasferire un sito web: l'architettura degli accessi rimane comprensibile ed efficiente. A tal proposito, ricordati di verificare che i backup del server siano effettivamente ripristinabili e non semplicemente generati.

Quali sono i vantaggi di una configurazione di accesso sicura?

Configurare un utente non-root dotato di privilegi sudo garantisce un ambiente di lavoro decisamente più sereno e controllato. Mantieni intatta la possibilità di installare software, aggiornare i servizi e risolvere malfunzionamenti, senza tuttavia applicare la massima autorità amministrativa a ogni singolo comando.

Il risultato è immediato: drastica riduzione del rischio di incidenti critici, totale chiarezza nella gestione dei permessi e una struttura di sistema semplice da comprendere anche a distanza di tempo.