Open SSH sécurité meilleures pratiques

Bien qu’Open SSH soit devenu la norme en matière de gestion de l'accès à distance, utiliser son installation par défaut comporte encore quelques risques en cybersécurité. Ce guide propose des moyens d’augmenter considérablement le niveau de sécurité d’une installation Open SSH.

Utiliser des clés chiffrées pour l’authentification est utile car cela élimine le besoin de saisir des mots de passe. Même les pirates les plus imaginatifs ne pourront pas interférer ou s’introduire dans une session, et il n’y a plus de tentatives de perçage de mots de passe.

1. Générer une paire de clés publique/privée en utilisant cette commande : $ ssh-keygen -t rsa. Cela crée deux fichiers dans le répertoire (caché) ~/.ssh ; la clé privée s’appelle id_rsa et la clé publique id_rsa.pub.

2. Choisir un mot de passe qui servira à déverrouiller la clé publique à chaque connexion. Optionnellement, ajouter un chiffrement protégé par une phrase de passe lors de la création de la clé.

   Appuyer sur Entrée sans entrer de phrase secrète fonctionne aussi. Cependant, sachez que créer une clé sans phrase secrète donne automatiquement un accès SSH au serveur distant à toute personne accédant à votre machine locale.

3. Copier la clé publique (id_rsa.pub) sur le serveur :

   Scp –p id_rsa.pub remoteuser@remotehost:
   

   Le remoteuser ne devrait jamais être root. Sélectionner plutôt l’utilisateur non-root par défaut en tant que remoteuser.

4. Se connecter avec SSH et copier la clé publique au bon endroit :

   ssh remoteuser@remotehost mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys mv id_rsa.pub ~/.ssh logout
   

5. Ensuite, supprimer la clé publique du serveur, sinon le client SSH n’autorisera pas la connexion au serveur :

   rm id_rsa.pub
   

6. Définir les permissions de fichiers sur le serveur (ces deux éléments sont requis si "StrictModes" est réglé sur yes) :

   $ chmod 700 ~/.ssh
   $ chmod 600 ~/.ssh/authorized_keys
   

7. Une fois connecté en utilisant la phrase secrète de la clé, désactiver totalement l’authentification par mot de passe. Pour ce faire, ouvrir le fichier /etc/ssh/sshd_config et ajouter les lignes suivantes :

   # Disable password authentication forcing use of keys
   PasswordAuthentication no
   

Pour éliminer complètement l’authentification basée sur les mots de passe et imposer l’utilisation de clés SSH ou de certificats, mettre à jour la configuration SSH en ajoutant les lignes suivantes dans le fichier /etc/ssh/sshd_config :

PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM no

Puis, redémarrer le service SSHD en saisissant soit /etc/init.d/sshd restart ou service sshd restart. Une fois fait, le serveur doit refuser toute connexion par nom d'utilisateur/mot de passe et accepter uniquement l’authentification par clé ou certificat.

Définir un intervalle d'expiration pour éviter d'avoir une session SSH sans surveillance. Pour cela, ouvrir le fichier /etc/ssh/sshd_config et ajouter la ligne suivante :

ClientAliveInterval 360
ClientAliveCountMax 0

L’intervalle d’inactivité est exprimé en secondes (360 secondes = 6 minutes). Une fois ce délai écoulé, les utilisateurs inactifs sont automatiquement déconnectés.

Pour une sécurité supplémentaire, il est recommandé d’empêcher l’accès distant depuis des comptes avec mot de passe vide. Ouvrir le fichier /etc/ssh/sshd_config et mettre à jour la ligne suivante :

PermitEmptyPasswords no

Dans les cas où l’authentification par nom d’utilisateur/mot de passe ne peut pas être évitée, il est recommandé de limiter la connexion SSH à certains utilisateurs qui ont besoin d’un accès à distance, afin de minimiser l’impact des utilisateurs aux mots de passe faibles.

Pour limiter la connexion SSH, ouvrir le fichier /etc/ssh/sshd_config et ajouter une ligne AllowUsers, suivie de la liste de noms d’utilisateurs séparés par un espace :

AllowUsers user1 user2

Ensuite, redémarrer le service SSHD en entrant soit /etc/init.d/sshd restart soit service sshd restart.

Pour désactiver la connexion root, ouvrir le fichier /etc/ssh/sshd_config en étant connecté en tant que root et modifier la ligne #PermitRootLogin en PermitRootLogin no. S’assurer d’enlever le symbole #, sinon cela ne fonctionnera pas.

Ensuite, redémarrer le service SSHD en entrant soit /etc/init.d/sshd restart soit service sshd restart.

Ouvrir le fichier /etc/ssh/sshd_config et ajouter ces lignes :

# Ciphers moderns
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# KEX robusts
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384

# MAC moderns
MACs hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

# Disable weak algorithms
PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512
HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512

Ensuite, redémarrer le service SSHD en entrant soit /etc/init.d/sshd restart soit service sshd restart.

La grande majorité des pirates cherchant des serveurs SSH ouverts vont rechercher le port 22, puisqu’il s’agit du port d’écoute par défaut de SSH pour les connexions entrantes. Pour faire fonctionner SSH sur un port différent, ouvrir le fichier /etc/ssh/sshd_config et ajouter les lignes suivantes :

#Run SSH on a non standard port
Port 2025 #Change me

Ensuite, redémarrer le service SSHD en entrant soit /etc/init.d/sshd restart soit service sshd restart.

S’assurer de modifier la redirection de port dans votre routeur et toutes les règles de pare-feu nécessaires. Il est recommandé d’informer les clients de tout changement de port afin qu’ils sachent sur quel port se connecter, puisque SSH n’écoutera plus sur le port standard.

Si changer le port SSH n'est pas faisable, déployer un jump server fournit un point de contrôle à confiance zéro robuste entre les clients et les systèmes internes. Cela centralise l'authentification, applique des politiques de contrôle d'accès uniformes et empêche l'exposition directe des actifs critiques. Voir Remote Desktop Manager Jump (fonctionnalité) pour les étapes de configuration.

L’authentification multifacteur est l’une des principales protections à ajouter aux serveurs SSH pour les protéger contre l’accès non autorisé, car chaque connexion utilisateur doit être reliée à un utilisateur MFA configuré. Même si un pirate parvient à obtenir un mot de passe ou à pénétrer sur le serveur SSH, il sera tout de même bloqué par la MFA.