Pourquoi ne pas continuer en root ?

Tout ce que vous lancez en root peut casser tout le système, faute de frappe comprise. Les bots essaient aussi le nom 'root' en premier, donc désactiver la connexion root retire la cible la plus devinée. Un utilisateur nommé avec sudo vous donne une pause avant chaque commande privilégiée et un journal de ce qui a été exécuté.

Et si je m'enferme dehors ?

Utilisez la console web de votre espace client. Elle fonctionne même quand SSH est cassé ou que le pare-feu vous bloque, pour que vous puissiez corriger sshd_config. C'est aussi pour ça qu'on teste le nouvel utilisateur avant de fermer la session root.

Faut-il autoriser sudo sans mot de passe ?

Pour un compte humain, gardez la demande de mot de passe : c'est une dernière ligne de défense si votre clé SSH fuit. Sudo sans mot de passe est raisonnable pour un utilisateur de déploiement dédié à l'automatisation, limité aux commandes dont il a vraiment besoin.

La commande sudo n'existe pas sur mon serveur Debian. Pourquoi ?

Les images Debian minimales ne l'incluent pas toujours. Installez-la en root avec 'apt install -y sudo', puis ajoutez votre utilisateur au groupe sudo.

Quel port SSH utiliser ?

Celui affiché dans votre espace client. Les offres avec IP dédiée utilisent le port 22 sur votre propre IP ; les offres NAT utilisent votre port SSH personnel.

Créer un utilisateur sudo sur un VPS et arrêter d'utiliser root

Créez un utilisateur non root avec sudo sur Ubuntu ou Debian, donnez-lui votre clé SSH, testez-le, puis coupez la connexion root — dans un ordre qui évite de vous enfermer dehors.

Presque chaque nouveau VPS démarre de la même façon : vous vous connectez en root, installez deux ou trois choses, et un mois plus tard vous êtes toujours root. Ça marche jusqu'au jour où un script collé supprime le mauvais répertoire. Mettre en place un utilisateur normal avec sudo prend cinq minutes, et l'ordre compte plus que les commandes — se tromper, c'est rester dehors.

Voici la séquence sûre pour Ubuntu 22.04/24.04 et Debian 12.

1. Créer l'utilisateur

En root :

adduser deploy
usermod -aG sudo deploy

adduser demande un mot de passe et quelques informations facultatives (appuyez simplement sur Entrée). Choisissez un vrai mot de passe : vous le taperez pour sudo. Sur une Debian minimale, lancez d'abord apt install -y sudo si la commande manque.

2. Lui donner votre clé SSH

Le plus simple est de copier les clés de root en gardant le bon propriétaire :

rsync --archive --chown=deploy:deploy /root/.ssh /home/deploy

Si vous préférez le faire à la main :

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

De mauvaises permissions sont la raison classique d'un échec silencieux de la connexion par clé. SSH ignore un authorized_keys modifiable par d'autres utilisateurs.

3. Tester avant de changer quoi que ce soit

Gardez la session root ouverte. Dans un nouveau terminal :

ssh -p 22 deploy@203.0.113.10
sudo whoami

Mettez votre IP et votre port — sur une offre NAT, c'est votre port SSH personnel de l'espace client. Si sudo whoami affiche root, tout va bien. Si la connexion échoue, vous avez encore la fenêtre root pour corriger.

4. Couper la connexion root

Maintenant, fermez la porte. Au lieu de modifier la configuration principale, créez un petit fichier complémentaire :

cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
EOF
sshd -t && systemctl reload ssh

sshd -t vérifie d'abord la syntaxe. Une configuration cassée plus un reload, c'est exactement comme ça qu'on finit dans la console. PasswordAuthentication no n'a de sens qu'une fois la connexion par clé fonctionnelle pour le nouvel utilisateur — ce que vous venez de tester.

Ouvrez encore un terminal et vérifiez que root est refusé et que deploy entre toujours. Fermez ensuite l'ancienne session root.

5. Optionnel : sudo sans mot de passe pour l'automatisation

Si un script de déploiement a besoin de sudo sans question, donnez-lui exactement ça et rien de plus :

visudo -f /etc/sudoers.d/deploy

deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp

Honnêtement, NOPASSWD: ALL est tentant, mais une clé volée devient alors root. Limitez-le aux commandes que l'automatisation exécute.

Si quelque chose tourne mal

La console web de votre espace client ne dépend ni de SSH ni du pare-feu. Connectez-vous-y, corrigez le fichier dans /etc/ssh/sshd_config.d/, rechargez, terminé. Nous avons détaillé toute la procédure dans comment revenir sur un VPS verrouillé.

Et ensuite

Passez vraiment à la connexion par clé uniquement : authentification par clé SSH.
Calmez le bruit des attaques par force brute : fail2ban.
Faites le tour du reste avec la checklist de sécurité d'un nouveau VPS.

Les options d'accès de chaque offre sont dans la documentation d'accès. Même un Nano à $3 mérite un utilisateur non root — c'est le gain de sécurité le moins cher qui soit.