Root peut tout faire, y compris ce que vous ne vouliez pas. Pas de confirmation, pas d'annulation, et après coup le journal dit que c'est root - ce qui ne vous apprend rien si plusieurs personnes ont le mot de passe.

Créer un utilisateur nommé

sudo adduser sara
sudo usermod -aG sudo sara        # Debian and Ubuntu
# sudo usermod -aG wheel sara     # RHEL, Alma and Rocky

Lui donner votre clé, puis tester avant de fermer quoi que ce soit

sudo mkdir -p /home/sara/.ssh
sudo cp ~/.ssh/authorized_keys /home/sara/.ssh/
sudo chown -R sara:sara /home/sara/.ssh
sudo chmod 700 /home/sara/.ssh
sudo chmod 600 /home/sara/.ssh/authorized_keys
Ouvrez un second terminal et connectez-vous avec le nouvel utilisateur AVANT de désactiver root ou de fermer la première session. Une faute de frappe dans un fichier de clés se rattrape tant qu'il vous reste une session, et devient un appel au support quand il n'en reste plus.

Puis fermer la porte root

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

sudo sshd -t && sudo systemctl reload ssh

Ce que sudo apporte et que root n'apporte pas

  • Chaque commande est journalisée avec le nom de la personne qui l'a lancée.
  • Une commande dangereuse réclame cinq caractères de plus, tapés exprès, et cela suffit à en rattraper quelques-unes.
  • On retire l'accès en sortant un compte d'un groupe, pas en changeant un mot de passe que tout le monde partage.

sudo sans mot de passe, avec précaution

L'automatisation a besoin de sudo sans invite. Limitez-le aux commandes qu'elle exécute réellement plutôt qu'à tout.

# sudo visudo -f /etc/sudoers.d/deploy
deploy ALL=(root) NOPASSWD: /bin/systemctl reload nginx, /bin/systemctl restart app
Ne modifiez jamais /etc/sudoers avec un éditeur ordinaire. visudo vérifie la syntaxe avant d'enregistrer, et un fichier sudoers cassé prive tout le monde de sudo d'un seul coup.