Guide de Configuration SSH : Créer des Clés, Désactiver le Mot de Passe Root et Sécuriser Votre VPS

Chaque VPS que vous lancez est immédiatement scanné par des bots qui essaient des mots de passe par défaut. En quelques minutes. Si vous vous connectez encore avec un mot de passe root, vous êtes à une attaque par force brute d’un serveur compromis.

Les clés SSH règlent ce problème. Elles sont plus robustes que n’importe quel mot de passe, plus rapides à utiliser, et vous permettent de désactiver entièrement la connexion par mot de passe. Voici comment tout mettre en place, plus comment vérifier quels ports sont exposés sur votre serveur.

Étape 1 : Créer une Paire de Clés SSH

Les clés SSH fonctionnent par paires — une clé privée (reste sur votre ordinateur, ne la partagez jamais) et une clé publique (va sur le serveur).

Sur macOS ou Linux

Ouvrez un terminal et exécutez :

ssh-keygen -t ed25519 -C "your@email.com"

Vous verrez :

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/you/.ssh/id_ed25519):

Appuyez sur Entrée pour accepter l’emplacement par défaut. Puis définissez une phrase de passe (recommandé) ou appuyez sur Entrée pour passer.

Cela crée deux fichiers :

Fichier	Ce que c’est	Le partager ?
~/.ssh/id_ed25519	Clé privée	Jamais
~/.ssh/id_ed25519.pub	Clé publique	Oui — à copier sur les serveurs

Sur Windows

Option A : Windows Terminal / PowerShell

ssh-keygen -t ed25519 -C "your@email.com"

Même processus que ci-dessus. Les clés sont enregistrées dans C:\Users\YourName\.ssh\.

Option B : PuTTYgen

1. Téléchargez PuTTY
2. Ouvrez PuTTYgen
3. Sélectionnez EdDSA (Ed25519)
4. Cliquez sur Generate et déplacez votre souris
5. Enregistrez la clé privée (.ppk) et copiez le texte de la clé publique

Pourquoi Ed25519 ?

Algorithme	Taille de la clé	Sécurité	Vitesse
RSA 4096	4096 bits	Bonne	Plus lent
Ed25519	256 bits	Excellente	Le plus rapide
ECDSA	256 bits	Bonne	Rapide

Ed25519 est le choix moderne par défaut — clés plus courtes, opérations plus rapides, sécurité robuste. Utilisez-le sauf si vous avez besoin de la compatibilité RSA avec de très anciens systèmes.

Étape 2 : Copier Votre Clé Publique sur le Serveur

Méthode 1 : ssh-copy-id (La plus simple)

ssh-copy-id root@your-server-ip

Entrez votre mot de passe une dernière fois. C’est fait. L’outil ajoute votre clé publique au fichier ~/.ssh/authorized_keys sur le serveur.

Méthode 2 : Copie manuelle

Si ssh-copy-id n’est pas disponible :

cat ~/.ssh/id_ed25519.pub | ssh root@your-server-ip \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Méthode 3 : Lors de la création du VPS

La plupart des fournisseurs vous permettent d’ajouter des clés SSH lors de la création d’un serveur :

• Hostinger — Collez la clé publique dans la section SSH Keys lors de la configuration
• Hetzner — Ajoutez les clés à votre compte, sélectionnez-les lors de la création du serveur
• DigitalOcean — Idem, sous Settings → Security → SSH Keys
• Vultr — Products → SSH Keys → Add SSH Key

C’est la meilleure approche — le serveur est sécurisé dès son démarrage.

Vérifier que ça fonctionne

ssh root@your-server-ip

Vous devriez vous connecter sans qu’on vous demande de mot de passe (ou uniquement votre phrase de passe de clé si vous en avez défini une).

Étape 3 : Désactiver la Connexion par Mot de Passe Root

Une fois que la connexion par clé SSH fonctionne, désactivez entièrement l’authentification par mot de passe. Cela rend les attaques par force brute impossibles.

Modifier la configuration SSH

sudo nano /etc/ssh/sshd_config

Trouvez et modifiez ces lignes (certaines peuvent être commentées avec #) :

# Désactiver l'authentification par mot de passe
PasswordAuthentication no

# Désactiver les mots de passe vides
PermitEmptyPasswords no

# Désactiver l'authentification challenge-response (PAM)
KbdInteractiveAuthentication no

# Optionnel : désactiver entièrement la connexion root (utilisez un utilisateur normal + sudo à la place)
# PermitRootLogin no

# Si vous voulez la connexion root mais UNIQUEMENT avec des clés :
PermitRootLogin prohibit-password

Appliquer les modifications

sudo systemctl restart sshd

⚠️ Attention : Avant de fermer votre session actuelle, ouvrez un nouveau terminal et testez que vous pouvez toujours vous connecter avec votre clé. Si vous vous bloquez l’accès, vous aurez besoin de l’accès console depuis le tableau de bord de votre fournisseur VPS.

Tester

Depuis une autre machine (ou essayez explicitement avec un mot de passe) :

ssh -o PreferredAuthentications=password root@your-server-ip

Vous devriez voir :

Permission denied (publickey).

Cela signifie que la connexion par mot de passe est désactivée. Seule votre clé SSH fonctionne maintenant.

Étape 4 : Vérifier les Ports Ouverts sur Votre VPS

Chaque port ouvert est une surface d’attaque potentielle. Vous devez savoir exactement ce qui est exposé.

Vérifier depuis l’intérieur de votre serveur

Lister tous les ports en écoute :

ss -tlnp

La sortie ressemble à :

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       128     0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=1234))
LISTEN  0       511     0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=5678))
LISTEN  0       511     0.0.0.0:443         0.0.0.0:*          users:(("nginx",pid=5678))
LISTEN  0       128     127.0.0.1:5432      0.0.0.0:*          users:(("postgres",pid=9012))

Ce que chaque colonne vous indique :

Colonne	Signification
0.0.0.0:22	Écoute sur toutes les interfaces (accessible publiquement)
127.0.0.1:5432	Écoute uniquement sur localhost (non accessible publiquement)
Process	Quel programme utilise le port

Point clé : Tout ce qui est sur 0.0.0.0 ou [::] est accessible depuis Internet. Tout ce qui est sur 127.0.0.1 est local uniquement.

Vérifier depuis l’extérieur de votre serveur

Cela vous indique ce qu’Internet voit réellement.

Avec nmap (le plus complet) :

# Installer nmap sur votre machine locale
# macOS: brew install nmap
# Ubuntu: sudo apt install nmap

# Scanner les ports courants
nmap your-server-ip

# Scanner TOUS les ports (prend plus de temps)
nmap -p- your-server-ip

# Scanner avec détection des services
nmap -sV your-server-ip

Avec netcat (vérification rapide d’un seul port) :

nc -zv your-server-ip 22
nc -zv your-server-ip 3306

Avec un scanner en ligne :

Visitez shodan.io et recherchez l’IP de votre serveur. Il affiche tous les ports et services détectés publiquement — exactement ce que les attaquants voient.

Quels ports devraient être ouverts ?

Pour un serveur web typique :

Port	Service	Doit-il être ouvert ?
22	SSH	✅ Oui (envisagez de le changer pour un port non standard)
80	HTTP	✅ Oui (redirige vers HTTPS)
443	HTTPS	✅ Oui
3306	MySQL	❌ Non — lier à localhost
5432	PostgreSQL	❌ Non — lier à localhost
6379	Redis	❌ Non — lier à localhost
27017	MongoDB	❌ Non — lier à localhost

Règle générale : Si un service n’a pas besoin d’être accessible depuis Internet, liez-le à 127.0.0.1.

Fermer les ports inutiles avec UFW

UFW (Uncomplicated Firewall) est le moyen le plus simple de gérer l’accès aux ports sur Ubuntu/Debian :

# Activer UFW (autorisez d'abord SSH !)
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# Vérifier le statut
sudo ufw status verbose

# Bloquer un port spécifique
sudo ufw deny 3306

# Autoriser uniquement depuis une IP spécifique
sudo ufw allow from 203.0.113.50 to any port 22

⚠️ Autorisez toujours SSH avant d’activer UFW. Sinon vous vous bloquerez l’accès.

Bonus : Renforcement SSH Supplémentaire

Changer le port SSH par défaut

Déplacer SSH du port 22 élimine 99 % des scans automatisés :

# /etc/ssh/sshd_config
Port 2222

sudo systemctl restart sshd
sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp

Puis connectez-vous avec :

ssh -p 2222 root@your-server-ip

Configurer un fichier SSH Config

Arrêtez de taper de longues commandes. Créez ~/.ssh/config sur votre machine locale :

Host myserver
    HostName 203.0.113.50
    User root
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Maintenant tapez simplement :

ssh myserver

Activer Fail2Ban

Fail2Ban surveille les fichiers journaux et bannit temporairement les IP ayant trop de tentatives de connexion échouées :

sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Vérifier les IP bannies
sudo fail2ban-client status sshd

Checklist de Sécurité Rapide

Après la configuration de tout nouveau VPS, passez en revue cette liste :

• Paire de clés SSH créée et copiée sur le serveur
• Authentification par mot de passe désactivée
• Connexion root définie sur prohibit-password ou désactivée
• UFW activé avec uniquement les ports nécessaires ouverts
• Bases de données liées à localhost uniquement
• Port SSH changé depuis le port 22 par défaut
• Fail2Ban installé et en cours d’exécution
• Paquets système mis à jour (apt update && apt upgrade)

FAQ

J’ai perdu ma clé SSH. Comment puis-je retrouver l’accès ?

Utilisez la console web de votre fournisseur VPS (disponible dans le tableau de bord de chaque fournisseur). Elle vous donne un accès terminal direct sans SSH. De là, vous pouvez ajouter une nouvelle clé publique ou réactiver temporairement l’authentification par mot de passe.

Puis-je utiliser plusieurs clés SSH ?

Oui. Ajoutez chaque clé publique sur sa propre ligne dans ~/.ssh/authorized_keys sur le serveur. Utile pour l’accès en équipe ou pour différents appareils.

Dois-je définir une phrase de passe sur ma clé ?

Oui, surtout sur les appareils partagés ou portables. Cela ajoute une deuxième couche — même si quelqu’un vole votre fichier de clé, il ne peut pas l’utiliser sans la phrase de passe. Utilisez ssh-agent pour éviter de la taper à chaque fois :

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Changer le port SSH est-il vraiment utile ?

Cela n’améliore pas la sécurité contre les attaques ciblées, mais élimine environ 99 % du trafic automatisé des bots. Moins de bruit dans vos journaux, moins de ressources gaspillées sur des tentatives échouées.

Comment savoir si quelqu’un essaie de s’introduire ?

Vérifiez votre journal d’authentification :

# Ubuntu/Debian
sudo tail -100 /var/log/auth.log | grep "Failed password"

# CentOS/RHEL
sudo tail -100 /var/log/secure | grep "Failed password"

Si vous voyez des milliers d’entrées provenant de différentes IP, c’est du scan normal de bots. C’est exactement pourquoi vous désactivez l’authentification par mot de passe.

Et Ensuite ?

Maintenant que SSH est verrouillé et que vous savez quels ports sont ouverts, vous avez couvert les vecteurs d’attaque les plus critiques. Pour approfondir la sécurité VPS, consultez notre guide de sécurité VPS et notre guide de configuration WireGuard pour les tunnels chiffrés entre serveurs.

Besoin d’un VPS pour vous entraîner ? Les plans KVM de Hostinger commencent à quelques euros par mois et vous donnent un accès root complet — parfait pour apprendre la sécurité serveur en pratique.