1.6. Rendre OpenSSH plus sûr

Désactivation des protocoles de connexion non sécurisés

• Pour que SSH soit vraiment efficace, il faut empêcher l'utilisation de protocoles de connexion non sécurisés qui sont remplacés par la suite OpenSSH. Sinon, le mot de passe d'un utilisateur peut être protégé par SSH pendant une session et être capturé plus tard lors d'une connexion par Telnet. Pour cette raison, envisagez de désactiver les protocoles non sécurisés, tels que telnet, rsh, rlogin et ftp.

Activation de l'authentification par clé et désactivation de l'authentification par mot de passe

• Le fait de désactiver les mots de passe pour l'authentification et de n'autoriser que les paires de clés réduit la surface d'attaque et peut également faire gagner du temps aux utilisateurs. Sur les clients, générez des paires de clés à l'aide de l'outil ssh-keygen et utilisez l'utilitaire ssh-copy-id pour copier les clés publiques des clients sur le serveur OpenSSH. Pour désactiver l'authentification par mot de passe sur votre serveur OpenSSH, modifiez /etc/ssh/sshd_config et remplacez l'option PasswordAuthentication par no:

  PasswordAuthentication no

Types de clés

• Bien que la commande ssh-keygen génère par défaut une paire de clés RSA, vous pouvez lui demander de générer des clés ECDSA ou Ed25519 en utilisant l'option -t. L'ECDSA (Elliptic Curve Digital Signature Algorithm) offre de meilleures performances que le RSA à puissance de clé symétrique équivalente. Il génère également des clés plus courtes. L'algorithme de clé publique Ed25519 est une implémentation des courbes d'Edwards torsadées qui est plus sûre et plus rapide que RSA, DSA et ECDSA.

  OpenSSH crée automatiquement les clés d'hôte RSA, ECDSA et Ed25519 du serveur si elles sont manquantes. Pour configurer la création de clés hôte dans RHEL, utilisez le service instancié sshd-keygen@.service. Par exemple, pour désactiver la création automatique du type de clé RSA :

  # systemctl mask sshd-keygen@rsa.service

  Note

  Dans les images où cloud-init est activé, les unités ssh-keygen sont automatiquement désactivées. En effet, le service ssh-keygen template peut interférer avec l'outil cloud-init et causer des problèmes avec la génération des clés de l'hôte. Pour éviter ces problèmes, le fichier de configuration drop-in etc/systemd/system/sshd-keygen@.service.d/disable-sshd-keygen-if-cloud-init-active.conf désactive les unités ssh-keygen si cloud-init est en cours d'exécution.

• Pour exclure certains types de clés pour les connexions SSH, commentez les lignes correspondantes dans /etc/ssh/sshd_config, et rechargez le service sshd. Par exemple, pour n'autoriser que les clés d'hôte Ed25519 :

  # HostKey /etc/ssh/ssh_host_rsa_key
  # HostKey /etc/ssh/ssh_host_ecdsa_key
  HostKey /etc/ssh/ssh_host_ed25519_key

Port autre que celui par défaut

• Par défaut, le démon sshd écoute sur le port TCP 22. La modification du port réduit l'exposition du système aux attaques basées sur l'analyse automatisée du réseau et augmente donc la sécurité par l'obscurité. Vous pouvez spécifier le port en utilisant la directive Port dans le fichier de configuration /etc/ssh/sshd_config.

  Vous devez également mettre à jour la politique SELinux par défaut afin d'autoriser l'utilisation d'un port autre que celui par défaut. Pour ce faire, utilisez l'outil semanage du paquetage policycoreutils-python-utils:

  # semanage port -a -t ssh_port_t -p tcp port_number

  En outre, mettez à jour la configuration de firewalld:

  # firewall-cmd --add-port port_number/tcp
  # firewall-cmd --runtime-to-permanent

  Dans les commandes précédentes, remplacez port_number par le nouveau numéro de port spécifié à l'aide de la directive Port.

Connexion racine

• PermitRootLogin est défini par défaut sur prohibit-password. Cela permet d'imposer l'utilisation d'une authentification par clé plutôt que par mot de passe pour se connecter en tant que root et de réduire les risques en empêchant les attaques par force brute.

  Attention

  L'activation de la connexion en tant qu'utilisateur root n'est pas une pratique sûre, car l'administrateur ne peut pas vérifier quels utilisateurs exécutent quelles commandes privilégiées. Pour utiliser les commandes administratives, connectez-vous et utilisez plutôt sudo.

Utilisation de l'extension X Security

• Le serveur X des clients Red Hat Enterprise Linux ne fournit pas l'extension X Security. Par conséquent, les clients ne peuvent pas demander une autre couche de sécurité lorsqu'ils se connectent à des serveurs SSH non fiables avec le transfert X11. De toute façon, la plupart des applications ne peuvent pas fonctionner avec cette extension activée.

  Par défaut, l'option ForwardX11Trusted du fichier /etc/ssh/ssh_config.d/05-redhat.conf est définie sur yes, et il n'y a pas de différence entre les commandes ssh -X remote_machine (hôte non fiable) et ssh -Y remote_machine (hôte fiable).

  Si votre scénario ne nécessite pas du tout la fonction de transfert X11, définissez la directive X11Forwarding dans le fichier de configuration /etc/ssh/sshd_config à no.

Restreindre l'accès à des utilisateurs, groupes ou domaines spécifiques

• Les directives AllowUsers et AllowGroups du fichier de configuration /etc/ssh/sshd_config vous permettent d'autoriser uniquement certains utilisateurs, domaines ou groupes à se connecter à votre serveur OpenSSH. Vous pouvez combiner AllowUsers et AllowGroups pour restreindre l'accès de manière plus précise, par exemple :

  AllowUsers *@192.168.1.*,*@10.0.0.*,!*@192.168.1.2
  AllowGroups example-group

  Les lignes de configuration précédentes acceptent les connexions de tous les utilisateurs des systèmes des sous-réseaux 192.168.1.* et 10.0.0.*, à l'exception du système portant l'adresse 192.168.1.2. Tous les utilisateurs doivent faire partie du groupe example-group. Le serveur OpenSSH refuse toutes les autres connexions.

  Notez que l'utilisation de listes d'autorisations (directives commençant par Allow) est plus sûre que l'utilisation de listes de blocages (options commençant par Deny) car les listes d'autorisations bloquent également les nouveaux utilisateurs ou groupes non autorisés.

Modification des politiques cryptographiques à l'échelle du système

• OpenSSH utilise les stratégies cryptographiques du système RHEL, et le niveau de stratégie cryptographique par défaut du système offre des paramètres sûrs pour les modèles de menace actuels. Pour rendre vos paramètres cryptographiques plus stricts, modifiez le niveau de stratégie actuel :

  # update-crypto-policies --set FUTURE
  Setting system policy to FUTURE

• Pour ne pas appliquer les politiques de cryptage à l'échelle du système pour votre serveur OpenSSH, décommentez la ligne contenant la variable CRYPTO_POLICY= dans le fichier /etc/sysconfig/sshd. Après cette modification, les valeurs spécifiées dans les sections Ciphers, MACs, KexAlgoritms, et GSSAPIKexAlgorithms du fichier /etc/ssh/sshd_config ne sont pas remplacées. Notez que cette tâche nécessite des connaissances approfondies en matière de configuration des options cryptographiques.
• Pour plus d'informations, voir Utilisation de stratégies cryptographiques à l'échelle du système dans le titre Durcissement de la sécurité.