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éfinissezPasswordAuthentication no. Après avoir effectué les modifications, redémarrez le service SSH :sudo sshd -t sudo systemctl reload sshdImportant : 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 directivePort. Par exemple, pour utiliser le port2222:Port 2222N'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.
AllowUsersetAllowGroups: Utilisez ces directives danssshd_configpour spécifier explicitement qui peut se connecter.AllowUsers admin user1 AllowGroups sshusersDenyUsersetDenyGroups: 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 nodanssshd_config.
5. Configurer le délai d'inactivité et les keepalives
Empêchez les sessions SSH actives sans surveillance de rester ouvertes indéfiniment.
ClientAliveIntervaletClientAliveCountMax: 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èsClientAliveCountMaxtentatives, 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,600ou400) 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
ProxyJumpou 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 fail2banousudo yum install fail2ban). - Configuration : Configurez les prisons dans
/etc/fail2ban/jail.localpour 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.