Connexion et Configuration SSH sur un VPS : Le Guide Complet de Sécurité

Secure shell (SSH) access est la pierre angulaire de la gestion professionnelle des serveurs. Que vous déployiez un site WordPress, que vous pousiez du code via Git, ou que vous administriez des applications personnalisées, SSH vous offre un tunnel chiffré et authentifié directement dans votre serveur. Ce guide complet vous guide à travers chaque étape — de votre première connexion au renforcement de votre configuration contre les attaques du monde réel — afin que vous puissiez gérer votre environnement VPS Hosting en toute confiance.

Pourquoi la sécurité SSH est importante

Chaque serveur accessible publiquement fait face à un barrage constant de tentatives de brute-force automatisées. Quelques minutes après qu’un VPS soit mis en ligne, les bots commencent à scanner le port 22 et à essayer des combinaisons courantes de nom d’utilisateur/mot de passe. Une configuration SSH mal sécurisée est l’un des points d’entrée les plus courants pour les attaquants.

La bonne nouvelle : quelques changements de configuration délibérés réduisent considérablement votre surface d’attaque. Combiné avec une infrastructure fiable — comme le stockage NVMe et la protection DDoS intégrée — une configuration SSH correctement renforcée vous offre un canal de gestion rapide, résilient et véritablement sécurisé.

Si vous n’avez pas encore choisi un environnement d’hébergement, envisagez d’explorer les plans VPS Hosting qui incluent un accès root complet, des ressources dédiées et la flexibilité de mettre en œuvre chaque mesure de sécurité couverte dans ce guide.

Prérequis

Avant de commencer, confirmez que vous avez les éléments suivants en place :

> Conseil : Si vous gérez plusieurs serveurs ou avez besoin d’une interface graphique en plus de SSH, consultez Panneaux de contrôle VPS pour des options comme cPanel, Plesk et DirectAdmin qui complètent l’accès en ligne de commande.

Connexion à votre VPS via SSH

Sur Linux ou macOS

Ouvrez votre terminal et exécutez :

ssh username@your_server_ip

Remplacez username par votre nom d’utilisateur réel (généralement root pour un VPS neuf) et your_server_ip par l’adresse IP publique de votre serveur.

Exemple :

ssh root@203.0.113.45

Invite de première connexion :

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Tapez yes et appuyez sur Entrée. Cela ajoute la clé d’hôte du serveur à votre fichier ~/.ssh/known_hosts. Lors des connexions suivantes, SSH vérifiera cette empreinte automatiquement — si elle change de manière inattendue, traitez-la comme un incident de sécurité potentiel.

Entrez votre mot de passe lorsque vous y êtes invité.

Sur Windows avec PuTTY

1. Téléchargez et ouvrez PuTTY depuis putty.org.
2. Dans le champ Host Name (or IP address), entrez l’adresse IP de votre serveur.
3. Confirmez que le Port est défini sur 22 et que le Connection type est SSH.
4. Cliquez sur Open.
5. Acceptez l’empreinte de la clé d’hôte lorsque vous y êtes invité.
6. Entrez votre nom d’utilisateur et votre mot de passe.

> Alternative Windows 10/11 : Windows Terminal et PowerShell incluent tous deux un client OpenSSH natif. Vous pouvez utiliser la même syntaxe ssh username@your_server_ip que sur Linux/macOS — aucun outil tiers requis.

Durcissement SSH : Configuration Étape par Étape

Tout le comportement SSH est contrôlé par un seul fichier de configuration :

/etc/ssh/sshd_config

Ouvrez-le avec des privilèges élevés :

sudo nano /etc/ssh/sshd_config

Travaillez sur chaque étape de durcissement ci-dessous. Après avoir apporté toutes les modifications, vous redémarrerez le service une fois — couvert dans la section suivante.

Étape 1 : Modifier le Port SSH par Défaut

Le port 22 est le premier port que les bots scannent. Déplacer SSH vers un port non standard élimine la grande majorité du bruit automatisé dans vos journaux.

Localisez cette ligne :

#Port 22

Changez-la en un port de votre choix (utilisez un numéro entre 1024 et 65535 qui n’est pas utilisé par un autre service) :

Port 2222

Supprimez le # pour décommenter la ligne. Enregistrez avec CTRL+X, puis Y, puis Entrée.

> Important : Avant de redémarrer SSH, assurez-vous que votre pare-feu autorise le nouveau port. Voir la note de pare-feu ci-dessous.

Mettez à jour votre pare-feu (exemple UFW) :

sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
sudo ufw reload

Mettez à jour votre pare-feu (exemple firewalld) :

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Étape 2 : Désactiver la Connexion Root

Autoriser la connexion directe root sur SSH est un risque de sécurité important. À la place, connectez-vous en tant qu’utilisateur ordinaire et augmentez les privilèges avec sudo si nécessaire.

Dans sshd_config, trouvez :

PermitRootLogin yes

Changez-le en :

PermitRootLogin no

Avant de désactiver la connexion root, assurez-vous que vous avez un utilisateur non-root avec les privilèges sudo :

# Create a new user
adduser adminuser

# Grant sudo privileges
usermod -aG sudo adminuser

Testez que cet utilisateur peut se connecter et exécuter les commandes sudo *avant* de désactiver la connexion root et de redémarrer SSH.

Étape 3 : Désactiver l’Authentification par Mot de Passe (Après Configuration des Clés)

Une fois l’authentification par clé SSH configurée (section suivante), désactivez complètement la connexion par mot de passe pour éliminer le risque de force brute :

PasswordAuthentication no

Assurez-vous également que ces directives connexes sont définies :

ChallengeResponseAuthentication no
UsePAM no

Étape 4 : Directives Recommandées Supplémentaires

Ajoutez ou vérifiez ces paramètres dans sshd_config pour une base de durcissement complète :

# Limit authentication attempts per connection
MaxAuthTries 3

# Disconnect idle sessions after 5 minutes
ClientAliveInterval 300
ClientAliveCountMax 2

# Disable empty passwords
PermitEmptyPasswords no

# Restrict SSH to specific users (replace 'adminuser' with your username)
AllowUsers adminuser

# Use only strong protocol version
Protocol 2

# Disable X11 forwarding if not needed
X11Forwarding no

Configuration de l’authentification par clé SSH

L’authentification par clé SSH remplace les mots de passe par une paire de clés cryptographiques : une clé privée qui reste sur votre machine locale et une clé publique qui se trouve sur le serveur. Même si un attaquant connaît votre nom d’utilisateur, il ne peut pas s’authentifier sans votre clé privée.

Étape 1 : Générer une paire de clés SSH (sur votre machine locale)

ssh-keygen -t ed25519 -C "your_email@example.com"

> Pourquoi Ed25519 ? C’est plus rapide et plus sécurisé que l’ancien algorithme RSA. Si votre système nécessite RSA pour la compatibilité, utilisez ssh-keygen -t rsa -b 4096 à la place.

Vous serez invité à choisir un emplacement de sauvegarde (~/.ssh/id_ed25519 par défaut convient) et à définir une phrase de passe. Définissez toujours une phrase de passe — elle chiffre votre clé privée afin que l’accès physique à votre machine ne compromette pas automatiquement vos serveurs.

Résultat :

Your identification has been saved in /home/you/.ssh/id_ed25519
Your public key has been saved in /home/you/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx your_email@example.com

Étape 2 : Copier la clé publique sur votre VPS

La méthode la plus simple utilise ssh-copy-id :

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@your_server_ip

Cette commande :

1. Se connecte à votre serveur en utilisant l’authentification par mot de passe.
2. Crée ~/.ssh/authorized_keys sur le serveur s’il n’existe pas.
3. Ajoute votre clé publique à ce fichier.
4. Définit automatiquement les permissions correctes.

Méthode manuelle (si ssh-copy-id n’est pas disponible) :

# On your local machine, display your public key
cat ~/.ssh/id_ed25519.pub

# On your server, add it manually
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "paste-your-public-key-here" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Étape 3 : Vérifier la connexion basée sur les clés avant de désactiver les mots de passe

Ne désactivez pas l’authentification par mot de passe tant que vous n’avez pas confirmé que la connexion basée sur les clés fonctionne. Ouvrez une nouvelle fenêtre de terminal et testez :

ssh -i ~/.ssh/id_ed25519 username@your_server_ip -p 2222

Si vous vous connectez avec succès sans être invité à entrer un mot de passe (seulement votre phrase de passe de clé, si définie), procédez à la désactivation de PasswordAuthentication dans sshd_config.

Redémarrage et vérification du service SSH

Après avoir enregistré toutes les modifications dans sshd_config, validez la syntaxe de la configuration avant de redémarrer :

sudo sshd -t

Si aucune erreur n’est retournée, redémarrez le daemon SSH :

sudo systemctl restart sshd

Vérifiez que le service a démarré avec succès :

sudo systemctl status sshd

Vous devriez voir Active: active (running) dans la sortie.

> Conseil de sécurité critique : Gardez votre session SSH actuelle ouverte lors du test de la nouvelle configuration dans une fenêtre séparée. Si quelque chose se passe mal, votre session existante reste active et vous pouvez annuler les modifications.

Test de Votre Configuration Sécurisée

Test 1 : Connexion sur le Nouveau Port avec Votre Clé

Depuis votre machine locale :

ssh username@your_server_ip -p 2222

Résultat attendu : Vous êtes connecté en utilisant votre clé SSH (invité à entrer la phrase de passe de votre clé si vous en avez défini une, mais pas le mot de passe de votre serveur).

Test 2 : Confirmer que la Connexion Root Est Bloquée

ssh root@your_server_ip -p 2222

Résultat attendu :

Permission denied (publickey).

ou

root@your_server_ip: Permission denied

Test 3 : Confirmer que l’Authentification par Mot de Passe Est Désactivée

ssh username@your_server_ip -p 2222 -o PubkeyAuthentication=no

Résultat attendu :

Permission denied (publickey).

Si l’authentification par mot de passe était toujours activée, vous seriez invité à entrer un mot de passe à la place.

Durcissement supplémentaire : Fail2Ban

Fail2Ban surveille les fichiers journaux et bannit automatiquement les adresses IP qui montrent des signes d’activité malveillante — comme les tentatives de connexion SSH échouées répétées. C’est un complément essentiel aux étapes de durcissement SSH ci-dessus.

Installer Fail2Ban

Ubuntu/Debian :

sudo apt update && sudo apt install fail2ban -y

CentOS/AlmaLinux/RHEL :

sudo dnf install epel-release -y
sudo dnf install fail2ban -y

Configurer Fail2Ban pour SSH

Créez un fichier de remplacement local (ne modifiez jamais directement le fichier jail.conf par défaut) :

sudo nano /etc/fail2ban/jail.local

Ajoutez ce qui suit :

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled  = true
port     = 2222
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s

Ajustez port pour correspondre à votre port SSH personnalisé. Enregistrez, puis activez et démarrez Fail2Ban :

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Vérifiez les bannissements actifs et l’état de la prison :

sudo fail2ban-client status sshd

Sauvegarde de vos clés SSH et de votre configuration

Un serveur verrouillé est un problème grave. Suivez ces pratiques pour l’éviter :

• Sauvegardez votre clé privée dans un gestionnaire de mots de passe chiffré ou un stockage hors ligne.
• Stockez une copie de sshd_config avant d’apporter des modifications : sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
• Utilisez la console hors bande de votre fournisseur d’hébergement (accès VNC/KVM via le panneau de contrôle) comme solution de secours si vous perdez l’accès SSH.
• Documentez votre port personnalisé — il est facile d’oublier 2222 lorsque vous basculez entre les serveurs.

Associer SSH à l’infrastructure d’hébergement appropriée

Une configuration SSH sécurisée n’est aussi forte que l’infrastructure qui la soutient. Considérez ces services complémentaires :

• Serveurs dédiés — Pour les charges de travail nécessitant des performances maximales et une isolation matérielle complète, les serveurs dédiés vous donnent un contrôle total sur les couches physiques et logicielles, y compris la configuration SSH.
• Certificats SSL — Sécurisez le côté web de vos applications avec des certificats SSL/TLS de confiance, complétant la sécurité SSH du backend de votre serveur.
• Enregistrement de domaine — Enregistrez et gérez votre domaine aux côtés de votre hébergement, ce qui facilite la configuration des contrôles d’accès basés sur DNS et des noms d’hôte du serveur.

Conclusion

Une configuration SSH correctement configurée est l’une des améliorations de sécurité à plus fort impact que vous puissiez apporter à n’importe quel serveur Linux. Pour résumer ce que vous avez implémenté :

Ces mesures fonctionnent ensemble pour créer une défense en couches — chacune étant significative en elle-même, et considérablement plus forte en combinaison.

Que vous exécutiez un seul site WordPress ou que vous gériez une flotte de serveurs d’applications, commencer par une configuration SSH renforcée vous met aux commandes. Associez-la à une infrastructure d’Hébergement VPS fiable, conservez vos clés en sauvegarde, et vous aurez un environnement serveur sécurisé et professionnel conçu pour durer.