Sécurisez l'accès à votre VPS par SSH et conservez une voie de récupération
SSH est souvent la porte d'entrée d'un VPS Linux. Une politique d'accès utile protège cette porte tout en conservant un moyen testé de rentrer. La séquence de modification la plus sûre prouve qu'un remplacement fonctionne avant de retirer la méthode d'accès existante.
L'essentiel à retenir
Vérifiez l'identité du serveur, utilisez des comptes individuels et des clés protégées, testez chaque modification de configuration dans une seconde session et conservez une procédure de récupération contrôlée séparément.
Commencez par un inventaire des accès et un chemin de récupération
Avant de modifier SSH, listez chaque moyen légitime d'accéder au serveur : comptes administrateurs, tâches de déploiement, clients de sauvegarde, agents de supervision et tout mainteneur tiers. Notez l'identité utilisée par chacun et s'il a besoin d'un shell, d'un transfert de fichiers ou d'une action automatisée restreinte. Une clé de déploiement oubliée peut rester utile à quelqu'un longtemps après le départ d'une personne du projet.
Confirmez comment l'accès serait rétabli si une règle de pare-feu ou une modification d'authentification échouait. Une console fournisseur ou un environnement de récupération peut être pertinent, mais ne supposez pas qu'un dispositif particulier soit inclus ou déjà configuré. Demandez à l'équipe de confirmer la voie disponible et qui est autorisé à l'utiliser. Conservez la procédure dans un emplacement privé qui reste accessible lorsque ce VPS est indisponible.
Gardez la session SSH active en cours ouverte pendant une modification planifiée. Utilisez un autre terminal pour les tests de nouvelle connexion. Une session existante qui continue de fonctionner ne prouve pas grand-chose quant à la capacité d'une nouvelle connexion à s'authentifier ; fermer le premier terminal est donc l'étape finale, et non le test lui-même.
Vérifiez l'hôte, puis établissez des identités individuelles
La clé d'hôte du serveur identifie la machine ; votre clé utilisateur vous authentifie auprès d'elle. Comparez l'empreinte de la clé d'hôte avec une valeur obtenue par un canal indépendamment fiable avant d'accepter une première connexion. Si une empreinte connue auparavant change, déterminez si une reconstruction ou une rotation de clé planifiée l'explique. Supprimer l'empreinte enregistrée uniquement pour faire disparaître l'avertissement contourne cette vérification d'identité.
Attribuez à chaque administrateur un compte nominatif et une clé SSH individuelle. Protégez la clé privée sur l'appareil de l'administrateur, de préférence avec une phrase secrète et un agent local approprié ou un processus de connexion utilisant une clé de sécurité matérielle. N'installez que la clé publique sur le serveur. Vérifiez le propriétaire et les permissions du répertoire personnel du compte, du répertoire SSH et du fichier des clés autorisées à l'aide de la documentation du système d'exploitation installé.
Pour un projet à deux personnes, notez quelle clé appartient à chaque personne et quand elle a été autorisée. Testez une nouvelle connexion en tant qu'utilisateur nommé et vérifiez séparément l'élévation administrative prévue. Partager une seule clé privée ou une connexion root routinière rend le départ, l'investigation et la révocation sélective inutilement difficiles.
Modifiez l'authentification dans un ordre que vous pouvez vérifier
| Contrôle | Décision à prendre | Preuve avant de durcir |
|---|---|---|
| Authentification par clé publique | Quels comptes nommés et quelles clés sont acceptés ? | Une nouvelle connexion par clé pour chaque administrateur requis |
| Authentification par mot de passe | Est-elle encore requise par un flux de travail approuvé ? | L'accès de remplacement et la récupération ont tous deux été testés |
| Authentification clavier-interactive | Une politique MFA ou PAM en dépend-elle ? | La séquence d'authentification complète prévue réussit |
| Accès root direct | L'administration quotidienne peut-elle utiliser des comptes nommés ? | Le chemin d'élévation requis fonctionne depuis une nouvelle session |
Traitez PasswordAuthentication et KbdInteractiveAuthentication comme des décisions distinctes. Désactiver l'authentification par mot de passe seule ne décrit pas toutes les voies d'authentification interactive, tandis que désactiver l'accès clavier-interactif sans discernement peut casser une configuration MFA prévue. Lisez la politique effective pour votre version d'OpenSSH installée et testez l'intégralité du parcours de connexion, y compris tout second facteur.
La configuration d'OpenSSH peut inclure des fichiers supplémentaires et des sections Match conditionnelles. Une ligne ajoutée en bas ne remplace pas nécessairement une valeur applicable antérieure. Validez la syntaxe avant d'appliquer une modification ; sur le flux de travail Ubuntu documenté, sudo sshd -t effectue cette vérification. Inspectez la configuration effective pour le contexte de connexion concerné et suivez les instructions de gestion des services du système d'exploitation. La validation de syntaxe ne prouve ni l'accessibilité réseau ni la réussite de l'authentification.
Limitez l'exposition sans confondre obscurité et protection
Si les administrateurs se connectent depuis des réseaux prévisibles, envisagez de restreindre le point d'entrée administratif à ces réseaux ou à un chemin d'accès privé géré de manière appropriée. Tenez compte du personnel en déplacement, des adresses résidentielles changeantes et des clients automatisés avant d'appliquer une restriction. Vérifiez la règle depuis une nouvelle connexion véritable et conservez la voie de récupération convenue tout au long de la modification.
Changer le port SSH peut réduire le bruit des analyses en arrière-plan, mais ne remplace ni une authentification forte ni des mises à jour opportunes. Évitez les redirections et le transfert d'agent inutiles dans les sessions quotidiennes. Une tâche de déploiement qui ne transfère que des fichiers ne doit pas hériter automatiquement des mêmes capacités qu'un administrateur humain. Limitez chaque identité d'automatisation à la tâche que son propriétaire peut expliquer.
Maintenez OpenSSH et le système d'exploitation via leur processus de mise à jour pris en charge. Examinez les échecs d'authentification parallèlement aux connexions réussies, aux réseaux sources et aux maintenances planifiées. Un grand nombre de tentatives publiques échouées justifie d'évaluer l'exposition ; ce n'est pas la preuve qu'un compte particulier a été compromis avec succès.
Terminez par une revue des accès reproductible
- Une nouvelle session vérifie l'empreinte d'hôte attendue et s'authentifie avec l'identité prévue.
- Chaque administrateur peut effectuer les travaux approuvés avec la méthode d'élévation requise.
- Les tâches de déploiement et de sauvegarde réussissent toujours avec leurs propres identités restreintes.
- L'ancienne méthode d'accès n'est supprimée qu'après validation du remplacement et des contrôles de récupération.
- L'accès au compte et les clés individuelles d'une personne qui part sont examinés rapidement.
Répétez la revue après l'ajout d'un mainteneur, la reconstruction d'un serveur ou la modification de votre politique d'authentification. Conservez l'inventaire des accès approuvés sans copier de clés privées dans des notes de projet ou des tickets d'assistance. Lors d'une demande d'aide, indiquez la référence du serveur, le système d'exploitation, l'heure approximative de l'échec et le message d'erreur exact non secret. Une description claire de l'échec est plus utile que le partage du contrôle d'un identifiant administrateur.
