WardtermClient SSH
FR
Télécharger

Comment créer un utilisateur avec accès SSH et sudo

Sur Ubuntu ou Debian, exécutez sudo adduser deploy puis sudo usermod -aG sudo deploy. Sur RHEL ou Fedora, exécutez sudo useradd -m -G wheel deploy puis sudo passwd deploy. Placez ensuite la clé publique dans /home/deploy/.ssh/authorized_keys, qui appartient à cet utilisateur, avec le dossier en mode 700 et le fichier en 600. Testez avant de fermer votre session.

Mis à jour le . Exécuté sur Ubuntu 24.04 et Debian 13 dans des conteneurs jetables, connexion par clé et sudo compris.

Créer l'utilisateur

Sur Ubuntu et Debian, adduser demande un mot de passe et quelques informations facultatives, que vous pouvez passer avec Entrée :

sudo adduser deploy
sudo usermod -aG sudo deploy

Le -a compte : sans lui, -G remplace les autres groupes de l'utilisateur. Une Debian minimale peut ne pas avoir sudo du tout, alors exécutez d'abord apt install sudo en root.

Sur RHEL, Rocky, AlmaLinux et Fedora, le groupe d'administration s'appelle wheel :

sudo useradd -m -G wheel deploy
sudo passwd deploy

Vérifiez le résultat :

id deploy
sudo -l -U deploy

Installer la clé SSH

Exécutez ceci sur le serveur, en remplaçant l'exemple par la clé publique de l'utilisateur. Cela définit le propriétaire et les modes en une seule étape :

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_keys

Cela écrit un nouveau fichier et remplace l'éventuel fichier existant : ne l'utilisez que pour un nouveau compte. Si le compte a un mot de passe et que la connexion par mot de passe est activée, vous pouvez plutôt faire ceci depuis votre propre machine, ce qui ajoute la clé :

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server

Sur les systèmes où SELinux est en mode enforcing, corrigez aussi les étiquettes :

sudo restorecon -R /home/deploy/.ssh

Les permissions qui comptent

CheminPropriétaireMode
/home/deploydeploynon modifiable par les autres, par exemple 750
/home/deploy/.sshdeploy700
/home/deploy/.ssh/authorized_keysdeploy600

L'erreur classique est de créer ces fichiers en root et d'oublier le propriétaire. Dans notre test, un fichier appartenant à root en mode 600 donnait ceci, car l'utilisateur ne peut pas le lire :

deploy@server: Permission denied (publickey,password).

Vérifiez avec ceci, et consultez Permission denied (publickey) si les propriétaires et les modes sont corrects mais que cela échoue encore :

sudo stat -c '%a %U %n' /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keys

Debian et Ubuntu sont plus tolérants avec les dossiers modifiables par le groupe quand ce groupe est le groupe privé de l'utilisateur : notre connexion fonctionnait encore avec .ssh en 775. Ne comptez pas dessus, car d'autres systèmes refusent. Respectez le tableau.

Testez avant de fermer votre session

Ouvrez un nouveau terminal et laissez l'ancien connecté :

ssh deploy@server
sudo whoami

La seconde commande doit afficher root après avoir demandé le mot de passe de deploy. C'est seulement alors que vous pouvez désactiver la connexion root ou la connexion par mot de passe.

Un utilisateur avec une clé et sans mot de passe

Pour un compte créé depuis un script :

sudo adduser --disabled-password --comment "" deploy

Sur les versions plus anciennes, comme Ubuntu 22.04, l'option est --gecos "". La connexion par clé fonctionnait encore dans notre test sur Ubuntu 24.04, mais sudo ne peut pas demander un mot de passe qui n'existe pas :

sudo: a password is required

Définissez un mot de passe, ou autorisez sudo sans mot de passe pour cet utilisateur. Créez toujours ce fichier avec visudo, qui refuse un fichier cassé :

sudo visudo -f /etc/sudoers.d/90-deploy

avec cette ligne à l'intérieur :

deploy ALL=(ALL) NOPASSWD:ALL

Mesurez le coût : quiconque obtient cette clé, ou un shell sous cet utilisateur, devient root immédiatement. L'automatisation en a parfois besoin, une personne qui se connecte à la main rarement. Voir utiliser sudo via SSH en toute sécurité.

Questions

Comment donner sudo à un utilisateur existant ?

Lancez sudo usermod -aG sudo nom_utilisateur sur Debian et Ubuntu, ou sudo usermod -aG wheel nom_utilisateur sur RHEL et Fedora. L'utilisateur l'obtient à sa prochaine connexion.

Pourquoi sudo me demande-t-il un mot de passe alors que je me connecte avec une clé ?

Les deux sont indépendants. La clé prouve votre identité à SSH. sudo demande le mot de passe du compte, sauf si le fichier sudoers dit autre chose.

Dois-je me déconnecter après avoir ajouté le groupe ?

Oui. L'appartenance aux groupes est lue à la connexion : une session ouverte avant usermod ne l'a pas.

Sources

Autres guides : SSH sur chaque système

Tous les guides