Initialisation Ubuntu complète : utilisateurs, SSH et sécurité fail2ban

À trois heures du matin, je fixais la ligne « Permission denied » dans le terminal, le dos trempé de sueur.

Je ne pouvais plus accéder au serveur. Juste parce que j’avais modifié une config SSH sans laisser de porte de secours.

C’était il y a trois ans, quand j’ai acheté mon premier VPS. Aujourd’hui, mes actions ressemblent à un manuel de ce qu’il ne faut pas faire : connexion root directe, mot de passe = date de naissance, port SSH 22 par défaut, pare-feu ? Jamais entendu parler. Résultat : le serveur a été scané en moins de deux semaines, les logs pleins de tentatives de force brute.

Franchement, la première réaction de beaucoup après l’achat d’un VPS, c’est d’installer des trucs et de déployer. Gestion des utilisateurs ? Durcissement SSH ? Trop compliqué, on verra plus tard. Pourtant, ce « plus tard » décide de la durée de vie de votre serveur.

Cet article a un seul objectif : partir de zéro et configurer un serveur Ubuntu fraîchement acheté (22.04 ou 24.04) en état sécurisé et utilisable. Utilisateurs, durcissement SSH, blocage automatique fail2ban — tout y est. À chaque étape, j’explique le pourquoi, pas seulement une liste de commandes à copier-coller.

Environ 10 minutes pour parcourir ce flux. Ensuite, votre serveur sera plus sécurisé que 80 % des machines « à nu » sur le web.

1. Préparation avant l’initialisation

Avant de commencer, préparez vos outils. Vous devez générer une paire de clés SSH en local.

Pourquoi des clés plutôt qu’un mot de passe ? En bref : un mot de passe peut être brute-forcé, une clé pratiquement pas. Une clé Ed25519 256 bits mettrait plus de temps à casser que l’âge de l’univers.

Génération de clé

Ed25519 est recommandé aujourd’hui : plus sûr que l’ancien RSA, clé plus courte. La commande est simple :

# macOS / Linux
ssh-keygen -t ed25519 -C "[email protected]"

# Windows (PowerShell, client OpenSSH requis)
ssh-keygen -t ed25519 -C "[email protected]"

Le programme demande où stocker la clé et si vous voulez une passphrase. Entrée pour le chemin par défaut ; la passphrase est optionnelle — plus sûre, mais à saisir à chaque connexion.

Après génération, deux fichiers en local :

• ~/.ssh/id_ed25519 — clé privée, à ne jamais divulguer
• ~/.ssh/id_ed25519.pub — clé publique, à transférer sur le serveur

Pour le terminal, le Terminal macOS suffit ; sous Windows, Windows Terminal ou MobaXterm conviennent. Ce n’est pas le sujet ici.

2. Utilisateurs et permissions

Connectez-vous d’abord en root (dernière fois en direct — vous le désactiverez ensuite) :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

ssh root@VOTRE_IP_SERVEUR

Pourquoi éviter root ?

En un mot : les conséquences sont trop lourdes.

Les droits root sont vastes ; une mauvaise suppression ou une config erronée peut ruiner le système. Pire : de nombreux scripts d’attaque ciblent root. Exposer root en SSH, c’est offrir une grosse cible.

Utilisez un compte standard au quotidien, sudo quand il faut. C’est le principe de base de la sécurité Linux.

Créer un utilisateur de déploiement

J’utilise le nom deploy (« déploiement »). Vous pouvez choisir le vôtre :

# Créer l'utilisateur (mot de passe et infos demandés)
adduser deploy

# Accorder sudo
usermod -aG sudo deploy

Ubuntu demande un mot de passe et des infos ; choisissez un mot de passe mémorisable, le reste peut rester vide (Entrée).

Transférer la clé publique

Transférez votre clé publique locale vers ce compte. Sur votre machine locale :

# macOS / Linux
ssh-copy-id deploy@VOTRE_IP_SERVEUR

# Windows (PowerShell)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@VOTRE_IP_SERVEUR "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Testez la connexion avec deploy :

ssh deploy@VOTRE_IP_SERVEUR

Ça marche ? Continuez avec deploy, ne revenez pas à root. Pour les droits admin, ajoutez sudo.

Scénario multi-utilisateurs

Si plusieurs personnes utilisent le serveur, créez un compte par personne :

# Compte pour un collègue
adduser zhangsan
usermod -aG sudo zhangsan

# Il transfère sa clé depuis sa machine
ssh-copy-id zhangsan@VOTRE_IP_SERVEUR

Chacun son compte : traçabilité et dépannage plus simples.

3. Durcissement SSH

C’est l’étape la plus centrale — et celle où l’on se retrouve le plus souvent « dehors ».

Avertissement : avant de modifier SSH, gardez la session actuelle ouverte et ouvrez une deuxième fenêtre pour tester. En cas d’erreur, vous pourrez corriger depuis l’autre session.

Éditer la configuration SSH

sudo nano /etc/ssh/sshd_config

Paramètres clés, ligne par ligne

1. Port

Port 22    # Valeur par défaut, à changer

Le port 22 est la cible privilégiée des scans mondiaux. Un port haut (22222, 54321) évite la plupart des scans aveugles.

Port 54321

Note : sur un cloud (Alibaba, Tencent, AWS, etc.), ouvrez le nouveau port dans le groupe de sécurité / pare-feu, sinon pas de connexion.

2. PermitRootLogin — interdire root

PermitRootLogin no    # Obligatoire

Root est la cible numéro un des attaques. Le désactiver réduit fortement la surface d’exposition.

3. PasswordAuthentication — désactiver le mot de passe

PasswordAuthentication no    # Clés uniquement

C’est la clé contre la force brute. Tant que la clé privée reste secrète, le mot de passe ne sert à rien pour un attaquant.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

4. Autres paramètres de sécurité

MaxAuthTries 3              # 3 tentatives max
ClientAliveInterval 300     # Déconnexion après 5 min d'inactivité
ClientAliveCountMax 2       # 2 échecs de keepalive max

Ces réglages limitent les connexions inactives et le nombre de tentatives de force brute.

Vérification en trois étapes

Ne redémarrez pas tout de suite :

Étape 1 : syntaxe

sudo sshd -t

Pas de sortie = syntaxe OK.

Étape 2 : test dans une nouvelle fenêtre

Gardez la session actuelle, ouvrez un autre terminal :

ssh -p 54321 deploy@VOTRE_IP_SERVEUR

Connexion OK ? La config fonctionne et vous n’êtes pas bloqué dehors.

Étape 3 : redémarrage

sudo systemctl restart sshd
# ou
sudo systemctl restart ssh

Retestez après redémarrage. L’étape n’est terminée que si la connexion reste OK.

Astuce

Si vous ne pouvez plus vous connecter, console VNC du fournisseur cloud, restaurez la config, redémarrez le service. D’où l’importance de garder une session ouverte avant toute modification SSH.

4. Blocage automatique avec fail2ban

Le durcissement SSH limite la force brute. Et si quelqu’un insiste ? Entre fail2ban.

Qu’est-ce que fail2ban ? Un outil qui surveille les logs et bannit les IP suspectes. Trop d’échecs de mot de passe ? Blocage automatique pendant un moment. Simple et efficace.

Installation et démarrage

sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Configurer la jail sshd

fail2ban organise les règles par « jail » (prison). SSH a une jail sshd par défaut.

Créez un fichier local (ne modifiez pas la config par défaut — elle serait écrasée à la mise à jour) :

sudo nano /etc/fail2ban/jail.local

Contenu :

[sshd]
enabled = true
port = 54321          # Votre port SSH
maxretry = 3          # 3 échecs = ban
findtime = 600        # Fenêtre de 10 minutes
bantime = 3600        # Ban 1 heure

Paramètres :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

• maxretry : échecs autorisés (défaut 5, ici 3 pour plus de strictesse)
• findtime : fenêtre en secondes. 600 s = 3 échecs en 10 min déclenchent le ban
• bantime : durée du ban en secondes. 3600 = 1 h ; 86400 = 1 jour, etc.

Redémarrez :

sudo systemctl restart fail2ban

Voir l’état des bans

# Toutes les jails
sudo fail2ban-client status

# Détail sshd
sudo fail2ban-client status sshd

Vous verrez la liste des IP bannies.

Débannir une IP

Si vous vous êtes banni par erreur (trop de mauvais mots de passe en debug) :

sudo fail2ban-client set sshd unbanip VOTRE_IP

Aller plus loin : règles personnalisées

fail2ban protège aussi Nginx, Apache, MySQL, etc. Même principe, jails dédiées. Hors scope ici pour rester concis.

5. Différences entre versions

Ubuntu 22.04 et 24.04 : même flux d’initialisation, quelques détails différents.

Tableau comparatif

Impact pratique

Bonne nouvelle : le processus de cet article est identique sur les deux versions. Chemins SSH, installation fail2ban, commandes utilisateur — inchangés.

Points d’attention :

1. OpenSSH 9.x (24.04) : config par défaut plus stricte, anciens algorithmes désactivés. Un vieux client SSH peut poser problème ; mettez-le à jour.

2. Images cloud : certaines images 22.04 incluent des scripts de monitoring qui peuvent entrer en conflit. Préférez l’image officielle propre, ou vérifiez les services existants avant d’initialiser.

3. Mise à niveau : avant de passer un serveur 22.04 en 24.04, faites un snapshot. do-release-upgrade fonctionne souvent, mais pour la sécurité, la prudence paie.

Comment choisir ?

• Nouveau projet : 24.04 directement — support plus long, logiciels plus récents.
• Projet existant : 22.04 si vous dépendez d’une version précise (ex. Python 3.10).
• Stabilité : 22.04 est mûr, les pièges sont connus.
• Nouveautés : 24.04 apporte de meilleures performances et un support matériel amélioré.

Conclusion

Récapitulons l’essentiel de cette initialisation :

Trio sécurité :

• Utilisateur standard, root désactivé
• SSH : port personnalisé, pas de mot de passe, clés uniquement
• fail2ban pour bannir les IP suspectes

Principes d’action :

• Garder une session ouverte avant de modifier la config
• Vérifier à chaque étape, ne pas précipiter le redémarrage
• Ne jamais divulguer la clé privée

Checklist de validation :

• Connexion SSH avec deploy sur le nouveau port
• root ne peut plus se connecter
• Connexion par mot de passe désactivée
• fail2ban actif

Cette config n’est que la première étape. Ensuite viennent le pare-feu (UFW), Docker, le déploiement d’applications… pour une autre fois.

Si vous bloquez en suivant ce tutoriel, commentez — je ne souhaite à personne de revivre mon drame de trois heures du matin, enfermé dehors.