Préserver l’accès SSH

Préserver l’accès SSH

Une politique restrictive peut bloquer les connexions qui ne sont pas explicitement autorisées. Si vous travaillez à distance, une règle SSH absente ou incorrecte peut vous empêcher de reprendre la main sur le serveur. Avant d’appliquer un changement, vérifiez le port de la session en cours et prévoyez une règle qui permet cet accès.

La leçon précédente vous a permis de préparer une politique par défaut, sans l’appliquer. Ici, vous établissez un contrôle préalable : déterminer quel port SSH est réellement utilisé, puis vérifier que la configuration proposée autorise votre accès avant d’activer un filtrage entrant restrictif.

Relever le port de la session actuelle

Ne supposez pas que SSH utilise le port 22 : le serveur peut avoir été configuré sur un autre port. Dans votre session SSH ouverte, consultez la variable d’environnement SSH_CONNECTION. Ses quatre valeurs indiquent l’adresse et le port du client, puis l’adresse et le port du serveur ; c’est la dernière valeur qui correspond au port SSH local auquel votre session est connectée.

printf '%s\n' "$SSH_CONNECTION"

198.51.100.24 53142 203.0.113.10 2222

Dans cet exemple, la session arrive sur le port 2222 du serveur : c’est ce port qu’il faut prendre en compte, et non celui du client. La sortie est illustrative ; utilisez la valeur affichée dans votre propre session. Si la variable est vide ou si plusieurs chemins d’administration sont possibles, vérifiez la configuration SSH et les consignes de votre hébergeur avant de poursuivre.

Contrôler la règle avant le durcissement

Une règle SSH doit correspondre au port effectivement utilisé et au besoin d’administration du serveur. Avant d’activer une politique restrictive, vérifiez que cette autorisation est présente dans le plan de configuration et qu’elle concerne bien le trafic destiné au serveur. À ce stade, ne transformez pas cette vérification en règle improvisée : les leçons suivantes détailleront la construction des critères iptables, puis l’application avec UFW.

Dans le projet fil rouge, la page de suivi indique déjà que le port SSH à autoriser doit être le port réellement utilisé. Pour l’instant, le travail reste préparatoire : aucune règle n’est ajoutée, aucune politique n’est activée et aucun fichier du projet n’est modifié. Cette discipline permet de garder le même état du serveur jusqu’à ce que vous disposiez d’une séquence d’application contrôlée.

À retenir

• Relevez le port SSH de la session en cours au lieu de supposer qu’il s’agit du port 22.
• Vérifiez que le plan prévoit une autorisation correspondant à ce port avant toute politique entrante restrictive.
• Gardez la session actuelle ouverte pendant le changement et testez une nouvelle connexion avant de la fermer.
• À cette étape, ne modifiez ni les règles du pare-feu ni les fichiers du projet.

Dans la prochaine leçon, vous construirez une règle iptables à partir de ses critères, en vous appuyant sur ce contrôle préalable de l’accès SSH.