Bonnes pratiques de sécurité Open SSH

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

Utiliser l'authentification par clés privée/publique

L'utilisation de clés chiffrées pour l'authentification est utile, car elle élimine le besoin de saisir des mots de passe. Même les pirates les plus ingénieux ne pourront pas interférer avec une session ou s'y introduire, et les tentatives de forçage de mot de passe seront également éliminées.

1. Générez une paire de clés publique/privée à l'aide de 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. Choisissez un mot de passe qui sera utilisé pour déverrouiller la clé publique à chaque connexion. Il est également possible d'ajouter un chiffrement protégé par une phrase secrète lors de la création de la clé.

   Appuyer sur Enter sans saisir de phrase secrète fonctionne également. Sachez cependant que la création d'une clé sans phrase secrète donne automatiquement un accès SSH au serveur distant à toute personne qui accède à votre machine locale.
3. Copiez la clé publique (id_rsa.pub) sur le serveur :

   Scp –p id_rsa.pub remoteuser@remotehost:
   ```   <div data-gb-custom-block data-tag="hint" data-style='danger'>Le `remoteuser` ne doit jamais être root. Sélectionnez plutôt l'utilisateur non root par défaut comme `remoteuser`.</div>

4. Connectez-vous avec SSH et copiez 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. Supprimez ensuite la clé publique du serveur, sinon le client SSH n'autorise pas la connexion au serveur :

   rm id_rsa.pub

6. Définissez les autorisations sur les fichiers du serveur (ces deux éléments sont requis si « StrictModes » est défini sur yes) :

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

7. Une fois connecté à l'aide de la phrase secrète de la clé, l'authentification par mot de passe peut être entièrement désactivée. Pour ce faire, ouvrez le fichier /etc/ssh/sshd_config et ajoutez-y les lignes suivantes :

   # Disable password authentication forcing use of keys
   PasswordAuthentication no

Désactiver l'authentification par nom d'utilisateur et mot de passe

Pour éliminer complètement l'authentification par mot de passe et forcer l'utilisation de clés ou de certificats SSH, mettez à jour la configuration SSH en ajoutant les lignes suivantes dans le fichier /etc/ssh/sshd_config :

PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM no

Redémarrez ensuite le service SSHD en saisissant /etc/init.d/sshd restart ou service sshd restart. Une fois cette opération effectuée, le serveur doit rejeter toutes les connexions par nom d'utilisateur/mot de passe et n'accepter que l'authentification par clé ou par certificat.

Configurer l'intervalle de délai d'inactivité

Un intervalle de délai d'inactivité peut être défini pour éviter qu'une session SSH ne reste sans surveillance. Pour ce faire, ouvrez le fichier /etc/ssh/sshd_config et ajoutez la ligne suivante :

ClientAliveInterval 360
ClientAliveCountMax 0

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

Désactiver les mots de passe vides

Pour une sécurité accrue, il est recommandé d'empêcher les connexions à distance depuis des comptes avec des mots de passe vides. Ouvrez le fichier /etc/ssh/sshd_config et mettez à jour la ligne suivante :

PermitEmptyPasswords no

Limiter l'accès SSH à quelques utilisateurs

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

Pour limiter la connexion SSH, ouvrez le fichier /etc/ssh/sshd_config et ajoutez une ligne AllowUsers, suivie de la liste des noms d'utilisateurs séparés par des espaces :

AllowUsers user1 user2

Redémarrez ensuite le service SSHD en saisissant /etc/init.d/sshd restart ou service sshd restart.

Désactiver la connexion root

Pour désactiver les connexions root, ouvrez le fichier /etc/ssh/sshd_config en étant connecté en tant que root et remplacez la ligne #PermitRootLogin par PermitRootLogin no. Assurez-vous de supprimer le symbole #, sinon cela ne fonctionnera pas.

Redémarrez ensuite le service SSHD en saisissant /etc/init.d/sshd restart ou service sshd restart.

Désactiver les chiffrements faibles

Ouvrez le fichier /etc/ssh/sshd_config et ajoutez-y ces lignes :

# Ciphers moderns
Ciphers [e-mail],[e-mail],[e-mail]

# KEX robusts
KexAlgorithms curve25519-sha256,[e-mail],ecdh-sha2-nistp256,ecdh-sha2-nistp384

# MAC moderns
MACs hmac-sha2-512,hmac-sha2-256,[e-mail]

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

Redémarrez ensuite le service SSHD en saisissant /etc/init.d/sshd restart ou service sshd restart.

Utiliser un port non standard

La grande majorité des pirates qui recherchent des serveurs SSH ouverts vont chercher le port 22, car par défaut, SSH écoute les connexions entrantes sur ce port. Pour exécuter SSH sur un port différent, ouvrez le fichier /etc/ssh/sshd_config et ajoutez les lignes suivantes :

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

Redémarrez ensuite le service SSHD en saisissant /etc/init.d/sshd restart ou service sshd restart.

Assurez-vous de modifier la redirection de port dans votre routeur et 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, car SSH n'écoutera plus les connexions sur le port standard.

Limiter l'exposition SSH avec des contrôles réseau

Si le changement de port SSH n'est pas envisageable, le déploiement d'un serveur de rebond offre un point de contrôle Zero-Trust solide entre les clients et les systèmes internes. Il centralise l'authentification, applique des politiques d'accès uniformes et empêche l'exposition directe des ressources critiques. Consultez Remote Desktop Manager Jump (feature) pour les étapes de configuration.

Activer l'authentification multifacteur

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