Aggiungere nuovi utenti su Linux da terminale

Creare un utente Linux da terminale senza lasciare buchi operativi

Aggiungere un nuovo utente su Linux non significa solo creare un nome e una password. In ambiente reale bisogna decidere shell, gruppi, home directory, accesso SSH, eventuale sudo e, soprattutto, quali permessi non concedere. Il comando giusto dipende dal tipo di account che vuoi ottenere: utente interattivo, account applicativo, account temporaneo, o profilo amministrativo con privilegi limitati.

La regola pratica è semplice: prima definisci il profilo d’uso, poi crei l’utente con il minimo necessario, infine verifichi che home, gruppi e login funzionino davvero. Saltare uno di questi passaggi è il modo più veloce per ritrovarsi con account inutilizzabili o, peggio, troppo permissivi.

Scelta rapida: `useradd` o `adduser`

Su molte distribuzioni Linux esistono due strade. `useradd` è il comando più universale e vicino al livello basso del sistema; `adduser` spesso è un wrapper più comodo, presente soprattutto su Debian e derivate. Se vuoi una procedura trasportabile tra server diversi, conviene ragionare in termini di `useradd` perché esplicita quasi tutto in modo chiaro.

Per un account umano tipico, l’obiettivo è quasi sempre: home directory creata, shell di login valida, password impostata o chiave SSH già pronta, gruppo primario coerente e, se serve, appartenenza a gruppi supplementari come `sudo`, `wheel`, `docker` o `www-data`.

Creazione base di un utente interattivo

Il comando minimo per creare un utente con home e shell è questo:

sudo useradd -m -s /bin/bash nomeutente

Qui `-m` crea la home directory, mentre `-s /bin/bash` imposta la shell di login. Se ometti `-m`, l’utente può essere creato ma senza home; se ometti `-s`, il sistema userà la shell predefinita del profilo o una shell non adatta al login interattivo, a seconda della distro e della configurazione locale.

Dopo la creazione, verifica subito che l’account esista e che i parametri siano quelli attesi:

getent passwd nomeutente
ls -ld /home/nomeutente

Nel primo output devi vedere utente, UID, GID, home e shell. Nel secondo devi trovare una directory di proprietà dell’utente, o almeno del gruppo previsto, con permessi coerenti con il tuo modello operativo.

Password, blocco iniziale e login controllato

Se l’utente deve autenticarsi con password, impostala subito:

sudo passwd nomeutente

In ambienti più rigorosi conviene creare l’account senza password iniziale e sbloccarlo solo dopo aver predisposto la chiave SSH o concordato il canale di accesso. In quel caso puoi creare l’utente e poi forzare il cambio password al primo login:

sudo passwd -e nomeutente

Questo approccio è utile quando vuoi ridurre la finestra di esposizione di una password temporanea. Dopo l’uso, verifica l’ageing con:

sudo chage -l nomeutente

L’output ti dice scadenza password, ultimo cambio e politiche di aging. È il controllo che spesso manca quando si crea un utente “al volo” e poi lo si dimentica per mesi.

Gruppi primari e gruppi supplementari

Il gruppo primario influenza proprietà dei file creati dall’utente. Quello supplementare serve per autorizzazioni aggiuntive. La distinzione è importante perché molti problemi di permessi nascono da un gruppo sbagliato, non dall’utente in sé.

Per creare un utente già assegnato a gruppi specifici, usa:

sudo useradd -m -s /bin/bash -G sudo,docker nomeutente

Se vuoi definire anche il gruppo primario, prima controlla che esista:

getent group nomegruppo

e poi crea l’utente con `-g`:

sudo useradd -m -s /bin/bash -g nomegruppo -G sudo nomeutente

Se l’obiettivo è dare accesso amministrativo, non assumere che `sudo` sia il gruppo giusto su ogni sistema. Su alcune famiglie storiche è `wheel`. La verifica più pulita è guardare il file di policy di sudo o i gruppi effettivamente usati dal sistema, non andare a memoria.

Account amministrativo con accesso sudo limitato

Creare un utente con accesso amministrativo non significa renderlo equivalente a root. In molte installazioni è meglio concedere `sudo` e lasciare la traccia di audit dei comandi eseguiti. Dopo aver aggiunto l’utente al gruppo giusto, verifica il contenuto della policy con:

sudo -l -U nomeutente

Se il comando mostra i privilegi attesi, sai che il vincolo è applicato. Se invece il gruppo è presente ma `sudo -l` non mostra nulla, il problema è nella configurazione di `sudoers` o in una policy centralizzata, non nella creazione dell’utente.

Quando devi intervenire su `sudoers`, usa sempre `visudo` per evitare errori di sintassi:

sudo visudo

Se preferisci un file dedicato, meglio ancora un frammento in `/etc/sudoers.d/` con permessi corretti. È una scelta più ordinata e più facile da rimuovere in rollback rispetto a una modifica sparsa nel file principale.

Creare un utente solo per SSH con chiave pubblica

Per un accesso moderno, la combinazione più pulita è: account senza password esposta, login via chiave SSH e, se serve, sudo separato. In questo scenario crei l’utente, prepari la directory `.ssh`, carichi la chiave pubblica e sistemi i permessi.

sudo useradd -m -s /bin/bash nomeutente
sudo mkdir -p /home/nomeutente/.ssh
sudo nano /home/nomeutente/.ssh/authorized_keys

Dopo aver incollato la chiave pubblica, imposta i permessi corretti. SSH è molto rigido su questo punto: se sbagli ownership o mode, il login fallisce senza troppe spiegazioni utili.

sudo chown -R nomeutente:nomeutente /home/nomeutente/.ssh
sudo chmod 700 /home/nomeutente/.ssh
sudo chmod 600 /home/nomeutente/.ssh/authorized_keys

Verifica lato server con i log del demone SSH, tipicamente in `/var/log/auth.log` o tramite journal:

sudo journalctl -u ssh -n 50 --no-pager
sudo journalctl -u sshd -n 50 --no-pager

La presenza di un errore sui permessi della home, della directory `.ssh` o del file `authorized_keys` è un segnale immediato che la parte più delicata non è la creazione dell’utente, ma la preparazione del suo profilo di accesso.

Account di servizio: quando non deve fare login

Non tutti gli utenti devono poter accedere con shell. Per un account applicativo o di servizio, spesso conviene impostare una shell non interattiva come `/usr/sbin/nologin` o `/bin/false`, a seconda della distribuzione e del comportamento desiderato.

sudo useradd -r -s /usr/sbin/nologin -d /var/lib/nomeapp nomeapp

L’opzione `-r` crea un account di sistema, utile per demoni e servizi locali. In questo caso la home non è una home “umana”, ma una directory di lavoro o di stato. Prima di usare questa modalità, controlla che il servizio che stai preparando sappia davvero dove leggere e scrivere i propri file.

La verifica minima è doppia: esistenza dell’utente e comportamento del servizio. Un check rapido è:

getent passwd nomeapp
sudo -u nomeapp /usr/sbin/nologin

Il secondo comando deve restituire un messaggio di blocco o chiudersi subito, non una shell. Se ottieni prompt, la shell di servizio non è stata impostata come pensavi.

Scadenza, disabilitazione e account temporanei

Un utente temporaneo va trattato come un accesso con data di fine. Il sistema offre strumenti per forzare la scadenza dell’account o della password. Se hai un contratto breve, una finestra di manutenzione o un accesso esterno da revocare automaticamente, questa parte non va lasciata al caso.

sudo chage -E 2026-12-31 nomeutente
sudo chage -M 30 -m 1 nomeutente

La prima riga imposta la scadenza dell’account; la seconda definisce il massimo e il minimo tra i cambi password. Dopo aver applicato la policy, controlla con `chage -l` che il sistema abbia recepito i parametri. Se l’account deve essere disabilitato subito, puoi bloccare la password:

sudo passwd -l nomeutente

Questo non elimina l’utente: impedisce il login basato su password. Se l’accesso avviene con chiave SSH, valuta anche la rimozione di `authorized_keys` o la disabilitazione dell’intero account in base al modello di rischio.

Verifiche post-creazione che evitano i problemi più comuni

Quando il comando è finito, il lavoro non è finito. Le verifiche minime che consiglio sono sempre le stesse perché intercettano gran parte degli errori reali:

1. Controlla l’anagrafica con getent passwd nomeutente e verifica shell, UID, home e GID.
2. Controlla i gruppi con id nomeutente e confronta il risultato con il profilo atteso.
3. Controlla ownership e permessi della home con ls -ld /home/nomeutente.
4. Se usi SSH, prova il login e guarda i log con journalctl -u ssh -n 50 o il file di auth della distro.
5. Se l’utente ha sudo, verifica la policy con sudo -l -U nomeutente.

Queste verifiche sono veloci e ti dicono subito se il problema è nella creazione dell’account, nei permessi del filesystem, nella policy sudo o nella configurazione SSH. È molto più efficiente di una revisione generica a posteriori.

Errori pratici che vedo spesso

Il primo errore è creare un utente senza `-m` e poi dimenticarsi di preparare manualmente la home. Il secondo è assegnare gruppi a memoria, senza verificare se il sistema usa davvero `sudo` o `wheel`. Il terzo è sbagliare i permessi della `.ssh`, ottenendo un accesso negato che sembra un problema di chiave ma in realtà è un problema di ownership.

Un altro caso classico è l’account di servizio creato con shell interattiva per comodità iniziale e mai corretto. Quel dettaglio diventa una superficie d’attacco inutile. Se un account non deve essere usato da una persona, la shell deve riflettere questa scelta, non il contrario.

Anche il naming merita disciplina. Evita nomi ambigui, maiuscole, caratteri speciali inutili e account riutilizzati per più scopi. Un utente ben nominato si capisce da solo quando lo rivedi sei mesi dopo nei log o nella lista dei gruppi.

Esempio completo: utente admin con SSH e sudo

Questo è un flusso pratico completo per un utente umano con accesso SSH e privilegi amministrativi tramite gruppo. È una base ragionevole per molti server Linux recenti:

sudo useradd -m -s /bin/bash -G sudo mario
sudo passwd mario
sudo mkdir -p /home/mario/.ssh
sudo nano /home/mario/.ssh/authorized_keys
sudo chown -R mario:mario /home/mario/.ssh
sudo chmod 700 /home/mario/.ssh
sudo chmod 600 /home/mario/.ssh/authorized_keys
id mario
sudo -l -U mario

Se il sistema non usa `sudo` come gruppo amministrativo, sostituiscilo con il gruppo corretto del tuo ambiente. Se vuoi ridurre ancora l’esposizione, evita la password e concedi solo chiavi SSH, lasciando la password disabilitata o bloccata secondo la policy interna.

Quando usare `useradd` con opzioni più mirate

In contesti più strutturati conviene specificare anche il commento descrittivo, il gruppo iniziale e, se necessario, una home diversa dal default. Questo aiuta negli inventari e negli audit interni.

sudo useradd -m -s /bin/bash -c "Mario Rossi - Operations" -g users -G sudo mario

Il campo `-c` finisce nel GECOS e può essere utile per identificare rapidamente l’account. Non abusarne: informazioni troppo dettagliate diventano solo rumore. Mantienilo leggibile e coerente con il tuo sistema di inventario, non con preferenze personali.

Disabilitare o rimuovere un utente in modo prudente

Quando un account non serve più, la rimozione va decisa con cautela. In molti casi è più sicuro disabilitarlo prima, osservare se qualcuno o qualcosa lo usa ancora, e solo dopo valutare l’eliminazione completa. Il comando di blocco password è il primo passo, non il finale.

sudo passwd -l nomeutente
sudo chage -E 0 nomeutente

Se devi rimuovere anche i file dell’utente, fai prima un backup o almeno una verifica del contenuto della home. La cancellazione definitiva è irreversibile sul piano operativo, quindi va trattata come change controllato, non come pulizia veloce.

In sintesi: crea l’utente con il minimo necessario, verifica subito che sia davvero utilizzabile o davvero bloccato, e lascia tracce chiare delle tue scelte. Su Linux la parte difficile non è il comando: è evitare configurazioni ambigue che funzionano “quasi” e poi si rompono nel momento sbagliato.