Journaux d'authentification d'un VPS neuf : 200 tentatives root / admin123 en quatre heures — robots, pas cible personnelle. Le serveur tombe non pas par zero-day SSH, mais parce que PasswordAuthentication yes traînait encore après installation. Quatre habitudes auraient fermé 95 % de cette surface.
SSH est la porte d'administration de votre VPS. Sur petit projet, c'est souvent la seule. La sécuriser ne demande pas un centre de sécurité — demande de la discipline de base.
Les scans automatiques ciblent le port 22 mondial en permanence. La bonne nouvelle : ils cherchent des configurations par défaut — mot de passe root, clés faibles, services obsolètes. Quatre habitudes bien appliquées réduisent drastiquement la surface sans outil exotique. Couplez-les avec pare-feu VPS et mises à jour régulières.
Habitude 1 : authentification par clé uniquement
Générez une clé Ed25519 localement, déployez la clé publique dans ~/.ssh/authorized_keys pour un utilisateur dédié. Dans /etc/ssh/sshd_config, définissez PasswordAuthentication no, PubkeyAuthentication yes, PermitRootLogin no. Testez une nouvelle session avant de fermer l'ancienne, puis rechargez sshd.
Une clé sans passphrase sur portable volé = clé maîtresse. Passphrase ou token matériel pour production.
Habitude 2 : utilisateur non-root plus sudo
Créez deploy ou admin dans le groupe sudo. Root direct interdit ; opérations via sudo journalisé. Désactivez les comptes démo de l'image cloud.
Habitude 3 : fail2ban (ou équivalent)
Prison sshd — bannir l'adresse IP après N échecs. Couplez avec pare-feu restrictif. Liste blanche IP bureau si fixe. Ne comptez pas sur le changement de port 22 seul — les scans couvrent toute la plage.
Habitude 4 : mise à jour et surface minimale
Correctifs sécurité automatiques (unattended-upgrades). Désinstallez services inutiles qui écoutent. MaxAuthTries 3, AllowUsers deploy si petite équipe.
Bastion et accès équipe
Multi-serveurs : un bastion SSH (adresse IP restreinte) ou VPN WireGuard ; production non exposée SSH public si possible. Clés différentes staging/production. Révoquez clés au départ employé — secrets déploiement inclut clés SSH CI.
| Mauvais | Mieux |
|---|---|
| root + mot de passe | utilisateur + clé + sudo |
| même clé partout | clés par environnement |
| SSH monde 0.0.0.0/0 | pare-feu IP admin |
Au-delà de SSH : ne pas oublier l'application
Durcir SSH ne remplace pas patcher WordPress, fermer phpMyAdmin exposé, ou retirer .env du dépôt — voir secrets déploiement. Beaucoup de compromissions petits VPS passent par applicatif ou fuite d'identifiants après un durcissement SSH réussi. Les quatre habitudes restent nécessaires ; elles ne suffisent pas seules.
Le sommet : SSH durci ne protège pas l'application
Décider et avancer sans angle mort
Générez une clé Ed25519 avec passphrase. Créez un utilisateur sudo et testez la connexion par clé. Désactivez authentification par mot de passe et connexion root SSH. Activez fail2ban et pare-feu restreignant le port 22. Documentez l'accès console de secours. Comparez hébergeurs avec console rescue via l'annuaire.
Questions fréquentes
Clé RSA ou Ed25519 ?
Ed25519 est recommandé pour un VPS neuf : clé courte, moderne et rapide à déployer. RSA 4096 reste acceptable si vous devez prendre en charge un environnement ancien. Sur un portable, protégez la clé privée avec une passphrase — ou un agent SSH verrouillé à la fermeture de session.
Désactiver root SSH complètement ?
Oui, une fois un utilisateur sudo créé et testé depuis une nouvelle session parallèle. Gardez la console hébergeur (KVM ou série) accessible : une erreur dans sshd_config peut vous exclure avant le prochain déploiement. Testez la connexion par clé avant de fermer la session root.
fail2ban suffit-il ?
Non seul. fail2ban complète les clés et la désactivation des mots de passe en bannissant les adresses IP après des échecs répétés. Réglez la durée de bannissement et whitelistez l'adresse IP fixe du bureau si vous en avez une — sinon vous risquez de vous bloquer après vos propres essais.
SSH sur plusieurs serveurs : comment organiser ?
Utilisez des clés distinctes par environnement (staging, production), un bloc Host dans ~/.ssh/config par serveur, et un bastion ou VPN WireGuard pour la production. Restreignez le port 22 via pare-feu VPS aux adresses admin autorisées ; révoquez les clés au départ d'un collaborateur.
SSH sécurisé : quatre habitudes évidentes — clés, pas root mot de passe, sudo, fail2ban — que trop de VPS n'appliquent qu'après le premier scan réussi.