Chapitre 5.3 — L’utilisateur deploy

⏱️ TL;DR — Travailler en root au quotidien est une faute de sécurité : une commande de trop, un script malveillant, et c’est toute la machine qui tombe. On crée donc un utilisateur normal — deploy — qu’on ajoute au groupe sudo (droits d’admin à la demande), à qui on copie sa clé SSH, et qu’on teste. Ensuite seulement on durcit sshd_config (rappel Partie 4 : PermitRootLogin no, PasswordAuthentication no) — l’ordre est vital pour ne pas se verrouiller dehors. À partir de là, tout le travail du cours se fait en deploy + sudo, jamais en root. C’est le pivot du durcissement : on ferme la porte root, la plus convoitée par les attaquants.

🎯 Objectifs

• Créer un utilisateur de travail deploy avec adduser.
• Lui donner les droits d’administration à la demande via le groupe sudo.
• Copier sa clé SSH (depuis la machine locale, ou en recopiant authorized_keys).
• Tester l’accès deploy + sudo avant de couper root — pour ne pas s’enfermer dehors.
• Durcir sshd_config dans le bon ordre : root off, mot de passe off.

Pourquoi quitter root : le moindre privilège

Depuis le début de cette partie, tu es connecté en root. C’était nécessaire pour un VPS neuf, mais c’est un état temporaire. Root peut tout faire, sans garde-fou : un rm mal ciblé efface le système, un script piégé s’exécute sans résistance, une faille dans un service tournant en root donne les pleins pouvoirs à l’attaquant. Le principe du moindre privilège (vu en Partie 3) dit l’inverse : on travaille avec le minimum de droits, et on monte en root ponctuellement, pour une commande précise, via sudo.

Concrètement : on crée un utilisateur normal, deploy, qui sera ton compte de travail quotidien. Quand une action demande les droits d’admin (installer un paquet, redémarrer un service), tu la préfixes de sudo — et cette élévation est explicite, tracée, et limitée à cette commande.

🔒 Sécurité — Root est la cible numéro un des attaquants : c’est le compte qui existe sur toutes les machines Linux, et le seul dont le nom est connu d’avance. Les robots de bruteforce ne testent quasiment que root. En désactivant la connexion root (bientôt) et en travaillant en deploy, tu fais disparaître cette cible : un attaquant doit d’abord deviner ton nom d’utilisateur, puis franchir la clé SSH. Deux inconnues au lieu de zéro.

Étape 1 — Créer l’utilisateur deploy

Toujours connecté en root, crée l’utilisateur avec adduser (l’outil convivial de Debian/Ubuntu, préférable à useradd bas niveau) :

🐚 Au terminal

adduser deploy
# Crée l'utilisateur "deploy", son groupe, son dossier /home/deploy et un shell.
# La commande demande un MOT DE PASSE : choisis-en un solide (il servira pour sudo).
# Les autres champs (nom complet, etc.) : tu peux les laisser vides (Entrée).

adduser fait tout le travail : il crée le compte, le dossier personnel /home/deploy, le shell par défaut, et te demande un mot de passe. Ce mot de passe ne servira pas à se connecter en SSH (on utilisera la clé), mais il servira à confirmer les commandes sudo — choisis-le donc robuste.

Étape 2 — Donner sudo à deploy

Sur Ubuntu/Debian, appartenir au groupe sudo donne le droit d’utiliser sudo. On ajoute deploy à ce groupe :

usermod -aG sudo deploy
# -a : ajoute (append) au groupe SANS retirer des groupes existants
# -G sudo : le groupe cible
# ATTENTION au -a : sans lui, usermod REMPLACE la liste des groupes (dangereux).

Le -a (append) est crucial : sans lui, usermod -G remplacerait tous les groupes de l’utilisateur par le seul groupe indiqué. Avec -aG, on ajoute sudo à ses groupes existants. Mémorise le duo -aG, toujours ensemble.

⚠️ Piège — Oublier le -a de usermod -aG. Un usermod -G sudo deploy (sans -a) écrase la liste des groupes de deploy et ne lui laisse que sudo — il perd son groupe primaire et d’autres appartenances, ce qui casse des choses subtiles. Toujours -aG, jamais -G seul pour ajouter un groupe.

Étape 3 — Copier la clé SSH de deploy

deploy existe et peut faire du sudo, mais il ne peut pas encore se connecter en SSH : il n’a pas de clé publique autorisée. Il faut copier ta clé publique dans son ~/.ssh/authorized_keys. Deux méthodes.

Méthode A — depuis ta machine locale (la plus simple)

Depuis ton poste (pas depuis le serveur), tant que la connexion par mot de passe est encore ouverte pour deploy :

# Sur TA MACHINE LOCALE :
ssh-copy-id deploy@203.0.113.10
# Copie ta clé publique (~/.ssh/id_ed25519.pub) dans authorized_keys de deploy.
# Demande le mot de passe de deploy (celui défini à l'étape 1).

ssh-copy-id s’occupe de tout : il crée ~/.ssh avec les bonnes permissions et ajoute ta clé. C’est la voie royale (revoir la Partie 4 sur la génération de clés ed25519).

Méthode B — recopier authorized_keys à la main

Si ssh-copy-id n’est pas disponible, ou si la connexion par mot de passe est déjà fermée, tu peux recopier la clé depuis root, qui l’a déjà dans son propre authorized_keys (le fournisseur l’y a mise à la création) :

🐚 Au terminal — sur le serveur, en root :

mkdir -p /home/deploy/.ssh                         # crée le dossier .ssh de deploy
cp /root/.ssh/authorized_keys /home/deploy/.ssh/   # recopie la ou les clés autorisées
chown -R deploy:deploy /home/deploy/.ssh           # deploy devient propriétaire (essentiel)
chmod 700 /home/deploy/.ssh                        # dossier accessible par deploy seul
chmod 600 /home/deploy/.ssh/authorized_keys        # fichier lisible par deploy seul

Les permissions sont critiques : SSH refuse d’utiliser un ~/.ssh ou un authorized_keys trop permissif (droits en écriture pour le groupe ou les autres). 700 sur le dossier, 600 sur le fichier, et surtout chown à deploy — sinon les fichiers appartiennent à root et deploy ne peut pas les lire.

💡 Réflexe — Après avoir posé une clé, teste la connexion deploy dans un NOUVEAU terminal, sans fermer ta session root actuelle. Tant que tu n’as pas confirmé que ssh deploy@ip fonctionne et que sudo répond, tu gardes ta session root ouverte comme filet. On ne coupe jamais un accès avant d’avoir validé le nouveau.

Étape 4 — Tester deploy + sudo AVANT de couper quoi que ce soit

C’est l’étape qu’on ne saute jamais. Ouvre un nouveau terminal sur ta machine locale (garde la session root ouverte à côté) :

# Sur ta machine locale, NOUVEAU terminal :
ssh deploy@203.0.113.10          # doit te connecter SANS mot de passe (par la clé)
whoami                            # doit afficher : deploy
sudo apt update                   # teste sudo : demande le mot de passe de deploy, puis exécute

Si ssh deploy@ip te connecte par la clé, que whoami dit deploy, et que sudo apt update fonctionne (après avoir tapé le mot de passe de deploy) : tout est bon. Tu peux passer au durcissement SSH. Si quoi que ce soit échoue, tu corriges depuis ta session root encore ouverte — sans risque de t’enfermer.

Étape 5 — Durcir SSH (dans le bon ordre)

Maintenant, et seulement maintenant que deploy + sudo + clé sont validés, on ferme les portes de root et du mot de passe. Ces réglages ont été introduits en Partie 4 ; on les applique ici, dans le contexte du provisioning. Édite la config du serveur SSH :

🐚 Au terminal — en deploy, avec sudo :

sudo nano /etc/ssh/sshd_config

Repère (ou ajoute) ces deux directives, et mets-les à no :

PermitRootLogin no
PasswordAuthentication no

• PermitRootLogin no — interdit toute connexion SSH directe en root. La cible n°1 des bruteforces disparaît.
• PasswordAuthentication no — interdit la connexion par mot de passe : seules les clés sont acceptées. Le bruteforce de mots de passe devient impossible (il n’y a plus de mot de passe à deviner).

Puis recharge la configuration SSH pour l’appliquer :

sudo systemctl restart ssh       # applique la nouvelle config (le service peut s'appeler ssh ou sshd)
# Sur certaines distros : sudo systemctl restart sshd

⚠️ Piège — Couper PermitRootLogin et PasswordAuthentication avant d’avoir testé que deploy se connecte par clé. Si ta clé n’est pas correctement en place et que tu désactives le mot de passe, tu te verrouilles dehors : plus de root, plus de mot de passe, et pas de clé qui marche. La règle d’or : garde ta session actuelle ouverte, ouvre une nouvelle connexion deploy pour vérifier, et ne durcis qu’après confirmation. (Filet ultime : la console de secours du fournisseur, dans son panneau web, qui accède à la machine hors SSH.)

🔒 Sécurité — Ces deux no sont parmi les gains de sécurité les plus rentables du serveur. PermitRootLogin no supprime la cible universelle ; PasswordAuthentication no rend le bruteforce structurellement impossible (pas de mot de passe = rien à forcer). Combinés à la clé ed25519 et, bientôt, à fail2ban et au pare-feu, l’accès SSH passe de « porte grande ouverte » à « coffre-fort ». Pense aussi à AllowUsers deploy pour restreindre explicitement qui peut se connecter.

À partir de maintenant : deploy + sudo, jamais root

Le changement de compte n’est pas cosmétique, c’est un changement de méthode pour tout le reste du cours. Désormais :

• Tu te connectes en deploy (ssh deploy@ip), jamais en root.
• Les commandes d’admin sont préfixées de sudo : sudo apt install, sudo systemctl restart nginx, sudo nano /etc/….
• Les services applicatifs (Node, Nginx, Postgres) tourneront eux aussi en utilisateurs dédiés non-root (Parties 7 et 9).

🧭 Sur FormaCampus — Sur formacampus-prod, l’équipe crée deploy, lui donne sudo, y colle la clé ed25519 de l’ingé responsable du déploiement, teste ssh deploy@formacampus-prod dans un second terminal, puis coupe root et le mot de passe. À partir de là, plus personne ne se connecte en root : les déploiements, les redémarrages de services, tout passe par deploy + sudo. Quand la CI/CD arrivera (Partie 13), c’est encore deploy (avec sa propre clé de déploiement) qui poussera les releases — jamais root. Le compte root devient un compte de secours qu’on n’utilise qu’en dernier recours via la console fournisseur.

📚 La doc — Toutes les directives de sshd_config sont documentées dans man sshd_config : PermitRootLogin, PasswordAuthentication, AllowUsers, PubkeyAuthentication, Port… C’est la référence exacte pour ta version. Pour adduser/usermod, voir man adduser et man usermod.

✏️ Exercices

Exercice 1 — Le bon ordre. Remets dans l’ordre ces gestes de création de deploy, et explique pourquoi cet ordre évite de s’enfermer dehors : (A) PermitRootLogin no ; (B) adduser deploy ; (C) tester ssh deploy@ip ; (D) usermod -aG sudo deploy ; (E) copier la clé SSH.

Exercice 2 — Permissions cassées. Tu as recopié authorized_keys à la main dans /home/deploy/.ssh/, mais ssh deploy@ip demande toujours un mot de passe (la clé est ignorée). Quelles sont les deux causes les plus probables et comment les corriger ?

🧠 Quiz de révision

Chapitre suivant : 5.4 — Le pare-feu (UFW) — fermer tous les ports par défaut et n’ouvrir que SSH, 80 et 443, sans se couper l’accès.