Crea l'utente
Su Ubuntu e Debian, adduser chiede una password e alcuni dati facoltativi, che puoi saltare con Invio:
sudo adduser deploy
sudo usermod -aG sudo deployLa -a conta: senza, -G sostituisce gli altri gruppi dell'utente. Un Debian minimale può non avere sudo, quindi esegui prima apt install sudo come root.
Su RHEL, Rocky, AlmaLinux e Fedora il gruppo degli amministratori è wheel:
sudo useradd -m -G wheel deploy
sudo passwd deployControlla il risultato:
id deploy
sudo -l -U deployInstalla la chiave SSH
Esegui questo sul server, con la chiave pubblica dell'utente al posto dell'esempio. Imposta proprietario e modi in un solo passaggio:
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
echo 'ssh-ed25519 AAAA... you@laptop' | sudo install -m 600 -o deploy -g deploy /dev/stdin /home/deploy/.ssh/authorized_keysQuesto scrive un file nuovo, sostituendo quello esistente, quindi usalo solo per un account nuovo. Se l'account ha una password e l'accesso con password è attivo, puoi invece farlo dal tuo computer, e la chiave viene aggiunta:
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@serverSui sistemi con SELinux in modalità enforcing, sistema anche le etichette:
sudo restorecon -R /home/deploy/.sshI permessi che contano
| Percorso | Proprietario | Modo |
|---|---|---|
/home/deploy | deploy | non scrivibile da altri, per esempio 750 |
/home/deploy/.ssh | deploy | 700 |
/home/deploy/.ssh/authorized_keys | deploy | 600 |
L'errore classico è creare questi file come root e dimenticare il proprietario. Nel nostro test un file di proprietà di root con modo 600 ha dato questo risultato, perché l'utente non riesce a leggerlo:
deploy@server: Permission denied (publickey,password).Controlla con questo comando, e se proprietari e modi sono giusti ma continua a fallire vedi Permission denied (publickey):
sudo stat -c '%a %U %n' /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keysDebian e Ubuntu sono più tolleranti con le cartelle scrivibili dal gruppo quando il gruppo è quello privato dell'utente: il nostro accesso funzionava anche con .ssh in modo 775. Non farci affidamento, perché altri sistemi lo rifiutano. Attieniti alla tabella.
Provalo prima di chiudere la sessione
Apri un nuovo terminale e lascia aperto quello vecchio:
ssh deploy@server
sudo whoamiIl secondo comando deve stampare root dopo aver chiesto la password di deploy. Solo allora è sicuro disattivare il login di root o l'accesso con password.
Un utente con chiave e senza password
Per un account creato da uno script:
sudo adduser --disabled-password --comment "" deployNelle versioni più vecchie, come Ubuntu 22.04, l'opzione è --gecos "". Nel nostro test su Ubuntu 24.04 l'accesso con chiave funzionava, ma sudo non può chiedere una password che non esiste:
sudo: a password is requiredImposta una password, oppure consenti sudo senza password a questo utente. Crea sempre quel file con visudo, che rifiuta un file sbagliato:
sudo visudo -f /etc/sudoers.d/90-deploycon questa riga dentro:
deploy ALL=(ALL) NOPASSWD:ALLTieni presente il costo: chiunque ottenga questa chiave, o una shell come questo utente, ha subito i privilegi di root. L'automazione a volte ne ha bisogno, una persona che entra a mano di rado. Vedi usare sudo via SSH in sicurezza.
Domande
Come do sudo a un utente che esiste già?
Esegui sudo usermod -aG sudo nomeutente su Debian e Ubuntu, oppure sudo usermod -aG wheel nomeutente su RHEL e Fedora. L'utente lo ottiene al login successivo.
Perché sudo mi chiede una password se entro con una chiave?
Sono due cose separate. La chiave dimostra a SSH chi sei. sudo chiede la password dell'account stesso, a meno che il file sudoers dica altro.
Devo uscire e rientrare dopo aver aggiunto il gruppo?
Sì. L'appartenenza ai gruppi viene letta al login, quindi una sessione aperta prima di usermod non ce l'ha.
Fonti
- sshd(8), AUTHORIZED_KEYS e permessi dei file, manuale OpenBSD
- sshd_config(5), StrictModes, manuale OpenBSD