SSH : connexion serveur, clés et bonnes pratiques

SSH revient dans presque toutes les conversations autour de l’hébergement : “accède en SSH à ton VPS”, “envoie ta clé SSH à l’agence”, “active SSH dans Plesk”… mais la plupart des ressources disponibles supposent que tu sais déjà de quoi il s’agit. Ce guide part de zéro : qu’est-ce que SSH, comment tu t’en sers concrètement en terminal, et quels risques il faut anticiper. Aucune connaissance préalable requise — juste un serveur (ou un VPS) auquel tu dois accéder.

Prérequis

• Avoir les identifiants de ton serveur : adresse IP (ou nom d’hôte), nom d’utilisateur, mot de passe ou clé SSH
• Un terminal disponible : Terminal sur Mac/Linux, PowerShell sur Windows 10+ (ou PuTTY)
• Les droits suffisants sur le serveur (accès SSH activé côté hébergeur — voir notre guide SSH sur Plesk si tu es sur cette interface)

1. C’est quoi SSH, concrètement

SSH signifie Secure Shell. C’est un protocole qui te permet de te connecter à un serveur distant et de l’administrer en ligne de commande, depuis ton propre ordinateur — comme si tu étais physiquement devant lui.

Avant SSH, on utilisait Telnet : fonctionnellement similaire, mais les échanges transitaient en clair sur le réseau. N’importe qui capable d’intercepter le trafic pouvait lire ton mot de passe. SSH chiffre l’intégralité de la session dès l’établissement de la connexion.

Par défaut, SSH écoute sur le port 22 de ton serveur.

À quoi ça sert dans la vraie vie ?

• Gérer un VPS ou un serveur dédié (installer des paquets, modifier des fichiers de config)
• Déployer une application manuellement ou via un pipeline CI/CD
• Lire les logs en temps réel pour diagnostiquer une panne
• Redémarrer un service (nginx, PHP-FPM, MySQL…) sans passer par un panel
• Transférer des fichiers de façon sécurisée via SCP ou SFTP

Si tu gères un site sur WordPress et que tu te demandes d’où vient un écran blanc ou une erreur critique, accéder aux logs serveur en SSH est souvent le chemin le plus rapide — bien plus direct que de fouiller dans les interfaces graphiques. Par exemple, une erreur critique WordPress révèle ses détails complets dans les logs PHP, accessibles en quelques secondes via SSH.

2. Se connecter au terminal : les commandes essentielles

La commande de base

Ouvre ton terminal (Mac/Linux) ou PowerShell (Windows 10+) et tape :

ssh utilisateur@adresse-ip

Exemple concret :

ssh marie@203.0.113.42

Si ton hébergeur utilise un port différent du port 22 :

ssh -p 2222 marie@203.0.113.42

À la première connexion, SSH te demande de confirmer l’empreinte du serveur (fingerprint). Tape yes pour l’accepter et l’enregistrer localement.

Mot de passe vs clé SSH

Mot de passe : simple à démarrer, mais vulnérable au brute-force et aux fuites. Évite-le en production.

Clé SSH : une paire de fichiers cryptographiques — clé privée (sur ta machine) + clé publique (sur le serveur). Même si quelqu’un intercepte la connexion, sans la clé privée il ne peut rien faire.

Génère ta paire de clés :

ssh-keygen -t ed25519 -C "ton-email@exemple.com"

Suis les invites. Choisis un emplacement (par défaut ~/.ssh/id_ed25519) et définis une passphrase — c’est le mot de passe qui protège la clé privée elle-même.

Dépose ta clé publique sur le serveur :

ssh-copy-id utilisateur@adresse-ip

Si ssh-copy-id n’est pas disponible (certains Windows), copie manuellement le contenu de ~/.ssh/id_ed25519.pub dans le fichier ~/.ssh/authorized_keys sur le serveur.

Commandes utiles une fois connecté

ls -lah          # lister les fichiers avec taille et permissions
cd /var/www/html # naviguer dans les répertoires
tail -f /var/log/nginx/error.log  # lire les logs en temps réel
systemctl restart nginx           # redémarrer un service
systemctl status php8.2-fpm       # vérifier l'état d'un service
exit                              # fermer la session SSH

Sur Windows, PowerShell intègre un client SSH natif depuis Windows 10 (1809+) — la commande ssh fonctionne exactement comme sur Mac/Linux. Sinon, PuTTY reste une alternative graphique fiable : renseigne l’IP, le port et ta clé privée (format .ppk avec PuTTYgen).

Pour des démarches propres à un hébergeur spécifique, le guide de connexion SSH sur Plesk détaille les étapes d’activation depuis le panel.

3. Les risques et les bonnes pratiques

SSH ouvre un accès direct au système — c’est sa force, et c’est aussi pourquoi la sécurité ne se négocie pas.

Ce qui arrive sans précautions

• Brute-force sur le port 22 : des bots scannent en permanence l’internet et testent des milliers de combinaisons utilisateur/mot de passe. Un serveur exposé avec un mot de passe faible est compromis en quelques heures.
• Connexion root directe : si root peut se connecter en SSH avec un mot de passe, une seule tentative réussie donne le contrôle total du serveur.
• Clé privée non protégée : si ta clé privée n’a pas de passphrase et qu’elle se retrouve dans un repo Git ou sur un ordinateur partagé, n’importe qui peut l’utiliser.

Les mesures à appliquer

Édite /etc/ssh/sshd_config sur ton serveur :

PasswordAuthentication no       # clés uniquement
PermitRootLogin no              # jamais root en direct
Port 2222                       # changer le port par défaut

Redémarre SSH après modification :

systemctl restart sshd

Installe fail2ban — il surveille les tentatives de connexion échouées et bannit automatiquement les IP suspectes :

apt install fail2ban   # Debian/Ubuntu

Autres bonnes pratiques :

• Restreins les connexions SSH aux IP connues (règles de pare-feu / iptables / panel hébergeur)
• Protège toujours ta clé privée avec une passphrase (voir génération plus haut)
• Maintiens le système à jour (apt upgrade ou équivalent) — les failles SSH sont régulièrement patchées
• N’utilise pas d’algorithmes de chiffrement anciens (RSA 1024 bits) : préfère ed25519

La sécurité de l’accès SSH rejoint la question plus large de la maintenance régulière d’un site web : un serveur qui n’est pas mis à jour et surveillé accumule des vulnérabilités silencieuses.

Pièges courants

• Fermer la session SSH avant de tester la nouvelle config : si tu modifies sshd_config et que tu coupes la connexion sans vérifier que la nouvelle connexion fonctionne, tu peux te retrouver bloqué dehors. Garde toujours une session ouverte pendant les tests.
• Oublier d’autoriser le nouveau port dans le pare-feu : changer le port SSH sans ouvrir ce port dans les règles firewall = blocage immédiat. Ouvre le port AVANT de redémarrer sshd.
• Copier la clé publique avec des retours à la ligne : authorized_keys doit contenir la clé sur une seule ligne. Une copie mal collée depuis un éditeur de texte casse l’authentification silencieusement.
• Confondre clé privée et clé publique : la clé publique (.pub) va sur le serveur ; la clé privée reste sur ta machine, jamais partagée, jamais uploadée.
• Se connecter depuis un réseau public sans passphrase : même avec une clé, si ta machine est compromise ou surveillée, l’absence de passphrase expose la session.

Un accès SSH bien configuré, c’est aussi l’une des conditions pour pouvoir récupérer un site web quand un prestataire a disparu — sans cet accès, la reprise de main prend bien plus de temps.