Meilleures pratiques de sécurité SSH : Renforcer votre serveur et votre client

Renforcez SSH avec l'authentification par clé, l'accès au moindre privilège, des habitudes client plus sûres, des règles de pare-feu, l'authentification multifacteur et la protection contre les attaques par force brute.

Meilleures pratiques de sécurité SSH : Renforcer votre serveur et votre client

Les meilleures pratiques de sécurité SSH sont importantes car SSH est souvent la porte d'entrée de vos serveurs. Une configuration SSH faible peut transformer un mot de passe deviné, une clé volée ou une erreur de confiance en un accès complet au shell.

Vous n'avez pas besoin de paramètres exotiques pour bien renforcer SSH. Commencez par une connexion basée sur les clés, des utilisateurs restreints, pas de connexion root directe, un comportement client prudent et des journaux qui vous montrent quand quelque chose ne va pas.

Renforcement de la sécurité côté serveur

Votre configuration du serveur SSH (sshd_config) définit les règles de connexion et d'authentification des clients.

1. Désactiver l'authentification par mot de passe

L'authentification par mot de passe est intrinsèquement vulnérable aux attaques par force brute. La remplacer par une authentification par clé SSH est l'une des améliorations de sécurité les plus efficaces que vous puissiez apporter.

  • Pourquoi : Les clés SSH sont bien plus complexes que les mots de passe et ne peuvent pas être facilement devinées ou craquées par des méthodes de force brute. Elles offrent une forme d'authentification beaucoup plus forte.

  • Comment : Modifiez votre fichier sshd_config (généralement situé dans /etc/ssh/sshd_config) et définissez PasswordAuthentication no. Après avoir effectué les modifications, redémarrez le service SSH :

    sudo sshd -t
    sudo systemctl reload sshd
    

    Important : Assurez-vous d'avoir configuré et testé avec succès l'authentification par clé SSH avant de désactiver l'authentification par mot de passe pour éviter de vous verrouiller.

Sur certaines distributions, le service est nommé ssh, pas sshd. Utilisez le nom de service fourni par votre système et gardez une session existante ouverte tout en testant une nouvelle connexion.

2. Considérez les changements de port comme une réduction du bruit

Changer le port SSH par défaut de 22 peut réduire le bruit des analyses automatisées. Ce n'est pas un substitut aux clés, aux correctifs et au contrôle d'accès.

  • Comment : Dans sshd_config, modifiez la directive Port. Par exemple, pour utiliser le port 2222 :

    Port 2222
    

    N'oubliez pas de mettre à jour vos règles de pare-feu pour autoriser le trafic sur le nouveau port et de spécifier le port lors de la connexion depuis votre client :

    ssh -p 2222 user@your_server_ip
    

3. Limiter l'accès des utilisateurs et des groupes

Contrôlez quels utilisateurs et groupes sont autorisés à se connecter via SSH.

  • AllowUsers et AllowGroups : Utilisez ces directives dans sshd_config pour spécifier explicitement qui peut se connecter.
    AllowUsers admin user1
    AllowGroups sshusers
    
  • DenyUsers et DenyGroups : Alternativement, utilisez-les pour bloquer des utilisateurs ou groupes spécifiques.

4. Désactiver la connexion root

La connexion root directe via SSH doit être désactivée pour empêcher les attaquants de cibler immédiatement le compte le plus puissant. Au lieu de cela, les utilisateurs doivent se connecter avec leurs propres comptes et utiliser sudo pour les tâches administratives.

  • Comment : Définissez PermitRootLogin no dans sshd_config.

5. Configurer le délai d'inactivité et les keepalives

Empêchez les sessions SSH actives sans surveillance de rester ouvertes indéfiniment.

  • ClientAliveInterval et ClientAliveCountMax : Ces paramètres côté serveur envoient des paquets nuls au client à intervalles réguliers pour vérifier si la connexion est toujours active. Si le client ne répond pas après ClientAliveCountMax tentatives, le serveur déconnecte la session.
    ClientAliveInterval 300  # Envoyer un paquet toutes les 5 minutes
    ClientAliveCountMax 2    # Déconnecter après 2 réponses manquées (10 minutes)
    

6. Renforcer les clés d'hôte

Assurez-vous que les clés d'hôte de votre serveur sont protégées et correctement gérées.

  • Permissions : Vérifiez que les fichiers de clés d'hôte (par exemple, /etc/ssh/ssh_host_rsa_key) ont des permissions restrictives (par exemple, 600) et appartiennent à root.
  • Algorithmes : Préférez les clés d'hôte modernes comme Ed25519 lorsque vos clients les prennent en charge. Ne supprimez pas les clés d'hôte existantes sans planification, car les clients verront cela comme un changement d'identité de l'hôte.
  • Rotation : Faites pivoter les clés d'hôte délibérément et annoncez les nouvelles empreintes via un canal de confiance.

Meilleures pratiques de sécurité côté client

Sécuriser votre machine cliente et vos clés SSH est tout aussi crucial que le renforcement côté serveur.

1. Protégez vos clés privées

Votre clé privée SSH est la passerelle vers vos serveurs. Traitez-la avec le plus grand soin.

  • Permissions : Assurez-vous que votre fichier de clé privée (par exemple, ~/.ssh/id_rsa) a des permissions strictes (par exemple, 600 ou 400) afin que vous seul puissiez le lire.
    chmod 600 ~/.ssh/id_rsa
    
  • Phrases de passe : Utilisez toujours une phrase de passe forte pour chiffrer votre clé privée. Cela ajoute une couche de sécurité supplémentaire, nécessitant la phrase de passe même si le fichier de clé est compromis.
  • Évitez de copier : Ne partagez votre clé privée avec personne et ne la stockez pas dans des endroits non sécurisés.

2. Utilisez le forwarding d'agent SSH avec précaution

Le forwarding d'agent SSH vous permet d'utiliser vos clés SSH locales pour vous authentifier sur des serveurs distants sans copier vos clés privées sur ces serveurs. Bien que pratique, cela peut être un risque de sécurité si le serveur distant est compromis.

  • Activer : ssh -A user@your_server_ip
  • Meilleure pratique : Désactivez le forwarding d'agent par défaut. Utilisez-le uniquement pour les hôtes auxquels vous faites confiance et préférez des alternatives telles que les clés de déploiement, le bastion ProxyJump ou les identifiants à courte durée de vie lorsqu'ils correspondent à votre flux de travail.

3. Vérifiez les empreintes des clés d'hôte

Lorsque vous vous connectez à un serveur SSH pour la première fois, votre client vous invite à vérifier l'empreinte de la clé d'hôte du serveur. Cela aide à prévenir les attaques de type homme du milieu.

  • Comment : Vérifiez toujours l'empreinte par rapport à une source de confiance, telle que votre console cloud, les journaux de provisionnement ou un administrateur. Si l'empreinte change de manière inattendue, arrêtez-vous et enquêtez avant de l'accepter.

4. Maintenez le logiciel client SSH à jour

Assurez-vous que votre logiciel client SSH (OpenSSH, PuTTY, etc.) est maintenu à jour pour bénéficier des derniers correctifs de sécurité et fonctionnalités.

Mesures de sécurité avancées

Au-delà des étapes fondamentales, envisagez ces techniques avancées :

1. Authentification multifacteur

Ajoutez l'authentification multifacteur pour l'accès SSH humain là où votre environnement le prend en charge. Cela combine généralement les clés SSH avec un code à usage unique, une approbation push ou une authentification basée sur le matériel.

  • Outils : Les modules PAM, Duo, les applications d'authentification et les clés de sécurité matérielles peuvent tous faire partie d'une conception d'authentification multifacteur SSH.

2. Fail2ban

Fail2ban analyse les journaux pour les tentatives d'authentification échouées répétées et peut ajouter des blocages temporaires de pare-feu pour l'IP source. Les chemins de journaux varient selon la distribution ; Debian et Ubuntu utilisent généralement /var/log/auth.log, tandis que de nombreux systèmes de la famille RHEL enregistrent via journald ou /var/log/secure.

  • Installation : Généralement disponible via les gestionnaires de paquets (sudo apt install fail2ban ou sudo yum install fail2ban).
  • Configuration : Configurez les prisons dans /etc/fail2ban/jail.local pour surveiller les journaux SSH et définir les durées de bannissement et les seuils.

3. Configuration du pare-feu

Utilisez un pare-feu (comme ufw, firewalld ou iptables) pour restreindre l'accès à votre port SSH (qu'il soit par défaut ou personnalisé) uniquement aux adresses IP ou plages de confiance.

  • Exemple (ufw) :
    sudo ufw allow from trusted_ip to any port 22
    sudo ufw enable
    

À retenir

Sécuriser SSH est une habitude continue. Utilisez l'authentification par clé, désactivez la connexion root directe, restreignez qui peut se connecter, protégez vos clés privées et vérifiez les empreintes des hôtes. Ajoutez ensuite des limites de pare-feu, l'authentification multifacteur et la protection contre la force brute là où le risque justifie la configuration supplémentaire.