Guide des ports SSH : accès sécurisé au serveur distant

SSH crée un canal chiffré entre un client et un serveur distant. Lors de la configuration de la connexion, le client vérifie la clé de l'hôte du serveur, les deux parties négocient le cryptage et l'utilisateur s'authentifie avec un mot de passe, une clé SSH, un certificat, une clé matérielle ou une autre méthode configurée.

Après l'authentification, SSH peut fournir un shell interactif, exécuter une seule commande à distance, transférer des ports, copier des fichiers ou des outils puissants tels que Git, rsync, Ansible et des pipelines de déploiement. Cette flexibilité explique pourquoi les SSH sont importants sur le plan opérationnel et pourquoi leur exposition nécessite une politique prudente.

Ouvrez SSH lorsque les administrateurs, les outils d'automatisation, les tâches CI/CD, la gestion de la configuration, les services Git ou les flux de travail brisés ont besoin d'un accès à distance à un serveur ou un appareil. Pour les serveurs de cloud public, SSH est souvent le premier chemin de gestion utilisé avant l'installation d'outils de niveau supérieur.

Ne publiez pas SSH sur l'ensemble d'Internet si seul un petit groupe a besoin d'y accéder. Préférez les VPN, les hôtes bastions, l’accès Zero Trust, les consoles série cloud, les listes autorisées d’IP source ou la connectivité réseau privée lorsque cela est possible. Si le SSH public est inévitable, appliquez dès le départ une authentification et une surveillance fortes.

Avant d'ouvrir le port 22, vérifiez que sshd est en cours d'exécution, écoute sur l'interface prévue et configuré pour le modèle d'authentification que vous souhaitez réellement. Décidez si les mots de passe sont autorisés, quels utilisateurs peuvent se connecter, si la connexion root est désactivée et comment les actions administratives seront auditées.

Un vérificateur de port peut confirmer si TCP 22 est accessible depuis l'extérieur de votre réseau, mais il ne peut pas prouver qu'un utilisateur peut se connecter en toute sécurité. Utilisez ssh -vvv, les journaux du serveur et les tests au niveau du compte pour valider la confiance de la clé hôte, les autorisations de clé, les stratégies MFA, l'accès au shell et les règles sudo.

Sur Windows Server, installez et activez le serveur OpenSSH, démarrez le service sshd et autorisez TCP 22 entrant dans le pare-feu Windows Defender. Les serveurs Windows hébergés dans le cloud doivent également correspondre aux règles de pare-feu cloud ou de groupe de sécurité.

Sous Linux, installez le serveur OpenSSH, vérifiez sshd_config et autorisez TCP 22 via le pare-feu hôte tel que ufw, firewalld, nftables ou iptables. Les instances cloud nécessitent également que le groupe de sécurité du fournisseur autorise les mêmes réseaux sources.

Sur macOS, activez la connexion à distance lorsque SSH est nécessaire sur les réseaux de confiance. Pour l'exposition sur Internet, appliquez les mêmes contrôles qu'un serveur : authentification par clé, étendue du pare-feu, journalisation et mises à jour en temps opportun.

Commencez par une vérification du port externe par rapport au nom d'hôte public ou à l'adresse IP et au port 22. Si le résultat est ouvert, le chemin TCP vers SSH est accessible. Exécutez ensuite ssh user@example.com ou ssh -vvv user@example.com pour vérifier la clé d'hôte, la méthode d'authentification et la configuration de la session.

Sur le serveur, confirmez l'écouteur avec ss -tlnp, netstat ou PowerShell. Si un serveur cloud est impliqué, comparez les règles de pare-feu hôte avec le groupe de sécurité cloud, car l'une ou l'autre couche peut bloquer SSH même lorsque l'autre semble correcte.

Si le port 22 est fermé, sshd peut être arrêté, installé sur un port différent, lié uniquement à une interface privée ou bloqué par le pare-feu hôte. Si la vérification expire, les paquets peuvent être supprimés par un groupe de sécurité cloud, une règle NAT de routeur, un filtre FAI, une politique VPN ou une liste blanche d'adresse IP source.

Si le port est ouvert mais que la connexion échoue, inspectez le nom d'utilisateur, les autorisations de clé, le fichier Authorized_keys, la politique de mot de passe, l'exigence MFA, les règles AllowUsers ou DenyUsers, les paramètres de connexion racine et les journaux du serveur. De nombreux échecs SSH sont des problèmes d’autorisation plutôt que des problèmes de port.

Désactivez la connexion root, préférez les clés ou les certificats aux mots de passe, faites pivoter les clés, supprimez les comptes obsolètes et limitez les personnes pouvant se connecter. Utilisez MFA ou des clés matérielles pour un accès privilégié et assurez-vous que les clés privées sont protégées par des phrases secrètes ou un stockage matériel sécurisé.

Réduisez la surface d'attaque grâce aux listes autorisées de sources, aux hôtes bastions, au VPN, à la limitation de débit, à la détection d'intrusion et aux correctifs OpenSSH opportuns. Déplacer SSH vers un port non standard peut réduire les analyses bruyantes, mais cela doit être traité uniquement comme une réduction du bruit, et non comme un contrôle de sécurité.