<<TableOfContents : execution failed « ]. (voir aussi le journal)>>
OpenSSH (ou Secure SHell) est devenu un standard de facto pour l’accès à distance remplaçant le protocole telnet. SSH a rendu les protocoles tels que telnet redondants en raison, en grande partie, du fait que la connexion est cryptée et que les mots de passe ne sont plus envoyés en texte clair à la vue de tous.
Cependant, une installation par défaut de ssh n’est pas parfaite, et lors de l’exécution d’un serveur ssh, il y a quelques étapes simples qui peuvent considérablement durcir une installation.
Utiliser des mots de passe/nom d’utilisateur forts
L’une des premières choses que vous remarquerez si vous avez ssh en cours d’exécution et exposé au monde extérieur est que vous enregistrerez probablement les tentatives des pirates pour deviner votre nom d’utilisateur/mot de passe. En général, un pirate recherche le port 22 (le port par défaut sur lequel ssh écoute) pour trouver les machines sur lesquelles ssh est exécuté, puis tente une attaque par force brute. Avec des mots de passe forts en place, on peut espérer que toute attaque sera enregistrée et remarquée avant qu’elle ne puisse réussir.
Espérons que vous utilisez déjà des mots de passe forts, mais si vous ne l’êtes pas, alors essayez de choisir des mots de passe qui contiennent :
- Minimum de 8 caractères
- Mélange de lettres majuscules et minuscules
- Mélange de lettres et de chiffres
- Caractères non alphanumériques (par exemple, des caractères spéciaux tels que ! » £ $ % ^ etc)
Les avantages des mots de passe forts ne sont pas spécifiques à ssh, mais ont un impact sur tous les aspects de la sécurité des systèmes. Vous trouverez de plus amples informations sur les mots de passe dans la documentation de CentOS :
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Si vous ne pouvez absolument pas empêcher vos utilisateurs de choisir des mots de passe faibles, alors envisagez d’utiliser des noms d’utilisateur générés de manière aléatoire ou difficiles à deviner pour vos comptes utilisateurs. Si les méchants ne peuvent pas deviner le nom d’utilisateur, ils ne peuvent pas forcer le mot de passe. Cependant, il s’agit toujours de la sécurité par l’obscurité et soyez conscient de la fuite d’informations des noms d’utilisateur à partir de choses telles que les courriels envoyés à partir des comptes d’utilisateurs.
Désactiver les logins root
Les paramètres du serveur SSH sont stockés dans le fichier /etc/ssh/sshd_config. Pour désactiver les connexions root, assurez-vous que vous avez l’entrée suivante :
# Prevent root logins:PermitRootLogin no
et redémarrez le service sshd :
service sshd restart
Si vous avez besoin de l’accès root, connectez-vous comme un utilisateur normal et utilisez la commande su.
Limiter les connexions des utilisateurs
Les connexions sshd peuvent être limitées à certains utilisateurs qui ont besoin d’un accès à distance. Si vous avez de nombreux comptes utilisateurs sur le système, il est alors logique de limiter l’accès à distance à ceux qui en ont vraiment besoin, limitant ainsi l’impact d’un utilisateur occasionnel ayant un mot de passe faible. Ajoutez une ligne AllowUsers suivie d’une liste de noms d’utilisateurs séparés par des espaces à /etc/ssh/sshd_config Par exemple :
AllowUsers alice bob
et redémarrez le service sshd.
Désactiver le protocole 1
SSH a deux protocoles qu’il peut utiliser, le protocole 1 et le protocole 2. L’ancien protocole 1 est moins sécurisé et devrait être désactivé à moins que vous sachiez que vous en avez spécifiquement besoin. Recherchez la ligne suivante dans le fichier /etc/ssh/sshd_config, décommentez-la et modifiez-la comme indiqué :
# Protocol 2,1Protocol 2
et redémarrez le service sshd.
Utiliser un port non standard
Par défaut, ssh écoute les connexions entrantes sur le port 22. Pour qu’un pirate puisse déterminer que ssh est en cours d’exécution sur votre machine, il va très probablement scanner le port 22 pour le déterminer. Une méthode efficace consiste à exécuter ssh sur un port non standard. Tout port inutilisé fera l’affaire, bien qu’un port supérieur à 1024 soit préférable. De nombreuses personnes choisissent le port 2222 comme port alternatif (car il est facile à retenir), tout comme le port 8080 est souvent connu comme le port alternatif HTTP. Pour cette raison, ce n’est probablement pas le meilleur choix, car tout pirate qui analyse le port 22 analysera probablement aussi le port 2222, pour faire bonne mesure. Il est préférable de choisir un port élevé aléatoire qui n’est utilisé pour aucun service connu. Pour effectuer ce changement, ajoutez une ligne comme celle-ci à votre fichier /etc/ssh/sshd_config :
# Run ssh on a non-standard port:Port 2345 #Change me
et redémarrez le service sshd. N’oubliez pas d’apporter ensuite les modifications nécessaires à la redirection des ports dans votre routeur et à toute règle de pare-feu applicable. Par exemple, sur CentOS 7 (et plus), vous pouvez modifier le service ssh de firewalld en faisant un double de son fichier de service dans /etc/firewalld/ et en modifiant sa ligne de port :
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Puis modifiez la ligne de port dans /etc/firewalld/services/ssh-custom.xml afin que le port soit le même que dans le fichier de configuration ssh :
<port protocol="tcp" port="2345"/>
Enfin, supprimez le service ssh, ajoutez le service ssh-custom, et rechargez firewalld pour que le changement prenne effet :
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Ou sur CentOS 6, ajoutez une règle iptable pour ouvrir le nouveau port ssh :
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
N’oubliez pas de fermer également l’ancien port.
Sur CentOS 6 et plus, vous devez également mettre à jour selinux, en étiquetant correctement le port choisi, sinon sshd sera empêché d’y accéder. Par exemple :
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Parce que ssh n’écoute plus les connexions sur le port standard, vous devrez indiquer à votre client sur quel port se connecter. En utilisant le client ssh depuis la ligne de commande, nous pouvons spécifier le port en utilisant le commutateur -p :
$ ssh -p 2345 myserver
ou si vous utilisez le protocole fish dans konqueror, par exemple :
fish://myserver:2345/remote/dir
Si vous pensez que cela semble être une douleur d’avoir à spécifier le port à chaque fois que vous vous connectez, ajoutez simplement une entrée spécifiant le port dans votre fichier local ~/.ssh/config :
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
Et le fichier : ~/.ssh/config doit avoir les permissions suivantes :
$ chmod 600 ~/.ssh/config
Filtrer SSH au niveau du pare-feu
Si vous n’avez besoin d’un accès distant qu’à partir d’une seule adresse IP (disons du travail vers votre serveur domestique), alors envisagez de filtrer les connexions au niveau de votre pare-feu en ajoutant une règle de pare-feu sur votre routeur ou dans iptables pour limiter l’accès sur le port 22 à cette adresse IP spécifique uniquement. Par exemple, dans iptables, cela pourrait être réalisé avec le type de règle suivant pour iptables (CentOS 6) :
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
ou en utilisant firwalld (CentOS 7) utiliser rich-rules pour autoriser ssh sur un port spécifique uniquement. L’adresse source peut être une adresse unique ou une adresse de base avec un masque de bits :
SSH supporte aussi nativement les wrappers TCP et l’accès au service ssh peut être contrôlé de manière similaire en utilisant hosts.allow et hosts.deny.
Si vous ne pouvez pas limiter les adresses IP sources et que vous devez ouvrir le port ssh de manière globale, alors iptables peut toujours aider à prévenir les attaques par force brute en enregistrant et en bloquant les tentatives répétées de connexion à partir de la même adresse IP. Par exemple, avec iptables
La première règle enregistre l’adresse IP de chaque nouvelle tentative d’accès au port 22 à l’aide du module récent. La deuxième règle vérifie si cette adresse IP a tenté de se connecter 4 fois ou plus au cours des 60 dernières secondes, et si ce n’est pas le cas, le paquet est accepté. Notez que cette règle nécessiterait une politique par défaut de DROP sur la chaîne d’entrée.
N’oubliez pas de modifier le port comme il convient si vous exécutez ssh sur un port non standard. Lorsque cela est possible, le filtrage au niveau du pare-feu est une méthode extrêmement efficace pour sécuriser l’accès à un serveur ssh.
Pour les systèmes utilisant le service FirewallD (CentOS 7 ou supérieur), utilisez firewall-cmd :
La première commande supprime la règle de service plus permissive, la seconde instaure une règle pour accepter seulement 4 connexions en une minute et enregistrer toutes les connexions.
Utiliser des clés publiques/privées pour l’authentification
L’utilisation de clés cryptées pour l’authentification offre deux avantages principaux. Premièrement, c’est pratique car vous n’avez plus besoin de saisir un mot de passe (sauf si vous cryptez vos clés avec une protection par mot de passe) si vous utilisez des clés publiques/privées. Deuxièmement, une fois que l’authentification par paire de clés publiques/privées a été configurée sur le serveur, vous pouvez désactiver complètement l’authentification par mot de passe, ce qui signifie que sans une clé autorisée, vous ne pouvez pas accéder – donc plus de tentatives de craquage de mot de passe.
C’est un processus relativement simple pour créer une paire de clés publiques/privées et les installer pour les utiliser sur votre serveur ssh.
D’abord, créez une paire de clés publiques/privées sur le client que vous utiliserez pour vous connecter au serveur (vous devrez le faire à partir de chaque machine cliente à partir de laquelle vous vous connectez) :
$ ssh-keygen -t rsa
Si vous ne voulez pas qu’on vous demande encore une phrase de passe (qui est essentiellement un mot de passe pour déverrouiller une clé publique donnée) à chaque fois que vous vous connectez, appuyez simplement sur la touche entrée lorsqu’on vous demande une phrase de passe lors de la création de la paire de clés. C’est à vous de décider si vous devez ou non ajouter le chiffrement de protection par phrase secrète à votre clé lorsque vous la créez. Si vous ne protégez pas votre clé par une phrase de passe, toute personne accédant à votre machine locale aura automatiquement un accès ssh au serveur distant. De plus, le super-utilisateur de la machine locale a accès à vos clés, bien que l’on puisse supposer que si vous ne pouvez pas faire confiance au super-utilisateur (ou si le super-utilisateur est compromis), vous avez de gros problèmes. Le cryptage de la clé ajoute une sécurité supplémentaire au prix de l’élimination de la nécessité de saisir un mot de passe pour le serveur ssh, qui sera remplacé par la saisie d’une phrase de passe pour l’utilisation de la clé. Ceci peut être encore simplifié par l’utilisation du programme ssh_agent
Now set permissions on your private key :
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Copiez la clé publique (id_rsa.pub) sur le serveur et installez-la dans la liste authorized_keys :
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Note : une fois que vous avez importé la clé publique, vous pouvez la supprimer du serveur.
et enfin définir les autorisations de fichiers sur le serveur :
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
Les permissions ci-dessus sont requises si StrictModes est défini à yes dans /etc/ssh/sshd_config (la valeur par défaut).
Assurez-vous que les contextes SELinux corrects sont définis :
$ restorecon -Rv ~/.ssh
Maintenant, lorsque vous vous connectez au serveur, vous ne serez pas invité à entrer un mot de passe (à moins que vous n’ayez entré une phrase de passe lorsque vous avez créé votre paire de clés). Par défaut, ssh essaiera d’abord de s’authentifier à l’aide de clés. Si aucune clé n’est trouvée ou si l’authentification échoue, alors ssh se rabattra sur l’authentification conventionnelle par mot de passe.
Une fois que vous avez vérifié que vous pouvez vous connecter avec succès au serveur en utilisant votre paire de clés publiques/privées, vous pouvez désactiver complètement l’authentification par mot de passe en ajoutant le paramètre suivant à votre fichier /etc/ssh/sshd_config :
# Disable password authentication forcing use of keysPasswordAuthentication no
Question fréquemment posée (FAQ)
Q : CentOS utilise la version X d’OpenSSH et la dernière version est la version Y. La version X contenait une grave faille de sécurité, dois-je la mettre à jour ?
A : Non. Le vendeur en amont a pour politique de rétrocomporter les correctifs de sécurité des dernières versions dans la version actuelle de la distribution. Tant que vous avez les dernières mises à jour appliquées pour votre distribution CentOS, vous êtes entièrement patché. Voir ici pour plus de détails sur le backport des correctifs de sécurité :
http://www.redhat.com/advice/speaks_backport.html
Q : Comment faire pour que ssh autorise l’authentification basée sur une clé sans mot de passe entre des machines qui partagent les répertoires personnels des utilisateurs par NFS ?
A : SElinux bloque l’accès root aux répertoires partagés NFS et aux fichiers qui ne sont pas lisibles par le monde par défaut et donc sshd ne peut pas lire les fichiers de clés des utilisateurs dans ~/.ssh. Pour permettre l’accès, modifiez le paramètre de use_nfs_home_dirs en exécutant la commande suivante en tant que superutilisateur :
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Liens
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html
.