Clé SSH | IWOFR

Une clé SSH est une créance d’accès dans le protocole SSH. Sa fonction est similaire à celle des noms d’utilisateur et des mots de passe, mais les clés sont principalement utilisées pour les processus automatisés et pour la mise en œuvre de l’authentification unique par les administrateurs système et les utilisateurs avancés.

Les clés SSH sont des justificatifs d’authentification

SSH (Secure Shell) est utilisé pour gérer les réseaux, les systèmes d’exploitation et les configurations. Il se trouve également à l’intérieur de nombreux outils de transfert de fichiers et de gestion des configurations. Toutes les grandes entreprises l’utilisent, dans tous les centres de données.

Les clés SSH permettent l’automatisation qui rend possible et rentable les services modernes de cloud computing et autres services dépendant de l’informatique. Elles offrent une commodité et une sécurité améliorée lorsqu’elles sont correctement gérées.

Fonctionnellement, les clés SSH ressemblent à des mots de passe. Elles accordent l’accès et contrôlent qui peut accéder à quoi. Dans la gestion des identités et des accès, elles nécessitent des politiques, un provisionnement et une résiliation similaires à ceux des comptes d’utilisateurs et des mots de passe. On ne peut pas avoir de confidentialité, d’intégrité ou de garantie de disponibilité continue des systèmes sans contrôler les clés SSH.

Techniquement, les clés sont des clés cryptographiques utilisant un système de cryptage à clé publique. Cependant, fonctionnellement, elles sont des justificatifs d’authentification et doivent être gérées comme telles.

Les clés autorisées définissent qui peut accéder à chaque système

Les clés autorisées sont des clés publiques qui accordent l’accès. Elles sont analogues aux serrures que la clé privée correspondante peut ouvrir.

Pour plus d’informations, consultez la page dédiée aux clés autorisées.

Les clés d’identité identifient les utilisateurs et fournissent l’accès

Les clés d’identité sont des clés privées qu’un client SSH utilise pour s’authentifier lorsqu’il se connecte à un serveur SSH. Elles sont analogues aux clés physiques qui peuvent ouvrir une ou plusieurs serrures.

Les clés autorisées et les clés d’identité sont appelées conjointement clés d’utilisateur. Elles concernent l’authentification de l’utilisateur, par opposition aux clés d’hôte qui sont utilisées pour l’authentification de l’hôte.

Pour plus d’informations, consultez la page dédiée aux clés d’identité.

L’authentification de l’utilisateur basée sur un certificat

Les certificats PKI peuvent également être utilisés pour l’authentification. Dans ce cas, l’utilisateur dispose toujours d’une clé privée mais aussi d’un certificat associé à cette clé. Cette technologie est prise en charge à la fois par Tectia SSH et OpenSSH, avec quelques différences. Pour plus d’informations, consultez la page dédiée à l’authentification par certificat dans SSH.

Les clés d’authentification des appareils

Les clés d’hôte authentifient les serveurs

Les clés d’hôte sont utilisées pour authentifier les hôtes, c’est-à-dire les ordinateurs. Leur but est d’empêcher les attaques de type man-in-the-middle. Consultez la page séparée sur les clés d’hôte pour plus d’informations.

L’authentification d’hôte basée sur un certificat peut être une alternative très intéressante dans les grandes organisations. Elle permet de faire tourner et de gérer les clés d’authentification des périphériques de manière pratique et de sécuriser chaque connexion.

Les clés d’hôte connues

L’une des caractéristiques uniques de SSH est que, par défaut, il fait confiance et se souvient de la clé de l’hôte lors de la première connexion à celui-ci. C’était un différentiateur clé qui a permis à SSH d’être déployé à la base, car il n’y avait pas d’infrastructure de clé centralisée pour les hôtes en 1995, et il n’y en a toujours pas aujourd’hui (2017), à l’exception des certificats SSL pour les serveurs web. La facilité de déploiement qui en résulte a été l’une des principales raisons du succès de SSH.

Les clés d’hôte mémorisées sont appelées clés d’hôte connues et elles sont stockées dans un fichier appelé known_hosts dans OpenSSH. Tant que les clés d’hôte ne changent pas, cette approche est très facile à utiliser et fournit une assez bonne sécurité. Cependant, dans les grandes organisations et lorsque les clés changent, la maintenance des fichiers d’hôtes connus peut devenir très chronophage. L’utilisation de certificats pour les clés d’hôtes est recommandée dans ce cas. Tectia SSH supporte les certificats X.509 standard pour les hôtes. OpenSSH possède son propre format de certificat propriétaire. L’avantage des certificats standard est qu’ils peuvent être émis par n’importe quelle autorité de certification (CA), alors qu’il n’existe aucune CA fiable pour les clés OpenSSH. Voir la page dédiée aux certificats avec SSH pour plus d’informations.

Clé de session

Une clé de session en SSH est une clé de chiffrement utilisée pour chiffrer la majeure partie des données d’une connexion. La clé de session est négociée pendant la connexion, puis utilisée avec un algorithme de chiffrement symétrique et un algorithme de code d’authentification de message pour protéger les données. Pour plus d’informations, consultez la page séparée sur les clés de session.

Comment configurer l’authentification basée sur les clés

L’authentification basée sur les clés dans SSH est appelée authentification par clé publique. Elle est facile à configurer par les utilisateurs finaux dans la configuration par défaut. En revanche, les organisations soucieuses de la sécurité doivent établir des politiques claires pour le provisionnement et la résiliation des accès basés sur les clés.

Comment configurer l’authentification par clé publique pour OpenSSH

Les clés SSH sont généralement configurées dans un fichier authorized_keys dans le .ssh sous-répertoire du répertoire personnel de l’utilisateur. Généralement, un administrateur système doit d’abord créer une clé à l’aide de ssh-keygen, puis l’installer en tant que clé autorisée sur un serveur à l’aide de l’outil ssh-copy-id. Voir également la page dédiée à la configuration des clés autorisées pour OpenSSH.

Nous recommandons d’utiliser des phrases de passe pour toutes les clés d’identité utilisées pour l’accès interactif. En principe, nous recommandons d’utiliser également des phrases de passe pour les accès automatisés, mais cela n’est souvent pas pratique.

Stockage des clés dans ssh-agent pour l’authentification unique

SSH est livré avec un programme appelé ssh-agent, qui peut contenir les clés privées déchiffrées de l’utilisateur en mémoire et les utiliser pour authentifier les connexions. L’agent peut également être utilisé pour accéder aux clés sur une carte à puce ou dans un module de sécurité matériel (HSM). Consultez la documentation de ssh-agent pour savoir comment le configurer.

La connexion à l’agent SSH peut être transmise à un serveur, de sorte que l’authentification unique fonctionne également à partir de ce serveur. Cette fonctionnalité doit être utilisée avec précaution, car elle permet à un serveur compromis d’utiliser les informations d’identification de l’utilisateur provenant de l’agent original. Le transfert d’agent peut cependant être une fonctionnalité de commodité majeure pour les utilisateurs puissants dans des environnements moins critiques en matière de sécurité.

Pour activer le transfert d’agent, définissez AllowAgentForwardingyes dans /etc/ssh/sshd_config sur le serveur et ForwardAgentyes dans le fichier de configuration du client /etc/ssh/ssh_config.

Tailles de clés recommandées

Nous recommandons de sélectionner les tailles de clés conformément à la norme NIST SP 800-57. Les tailles de clés par défaut utilisées par l’outil ssh-keygen sont généralement d’une force acceptable. En fait, comme le protocole ne révèle jamais les clés publiques acceptables pour l’authentification des utilisateurs, les algorithmes utilisés pour les clés ne sont pas aussi critiques qu’ils le sont, par exemple, dans les certificats PKI.

Pour les clés RSA, 2048 bits est probablement un bon choix aujourd’hui (2017). Cependant, de nombreux cryptographes recommandent maintenant de passer à des clés ECDSA et pensent que les avancées dans la factorisation des grands entiers pourraient rendre les clés RSA vulnérables à court/moyen terme. Pour ECDSA, nous recommandons d’utiliser des clés de 521 bits (sic !), même si des clés de 384 ou même 256 bits seraient probablement sûres. Il n’y a tout simplement aucun avantage pratique à utiliser des clés plus petites.

L’emplacement des clés d’identité

Les clés d’identité sont généralement stockées dans le répertoire .ssh d’un utilisateur, par exemple, .ssh/ssh_id_rsa. Le nom du fichier de clé d’identité par défaut commence par id_<algorithm>. Cependant, il est possible de spécifier n’importe quel nom de fichier et n’importe quel emplacement lors de la création d’une clé privée, et de fournir le nom du chemin d’accès avec l’option -i au client SSH. Par exemple, ssh -i /home/ylo/secure/my-key [email protected] utiliserait une clé privée du fichier my-key pour l’authentification.

L’emplacement de la clé d’identité par défaut peut également être configuré dans /etc/ssh/ssh_config ou dans le fichier .ssh/config de l’utilisateur à l’aide de l’option IdentityFile.

Emplacement des clés autorisées

Lorsqu’un utilisateur tente de se connecter en utilisant l’authentification par clé, le serveur OpenSSH recherche les clés autorisées dans un répertoire spécifié dans la configuration du serveur à l’aide de l’option AuthorizedKeysFile. La valeur par défaut est .ssh/authorized_keys dans le répertoire personnel de l’utilisateur.

Cependant, le fait que les clés autorisées soient stockées dans le répertoire personnel de l’utilisateur signifie que ce dernier peut ajouter de nouvelles clés qui autorisent les connexions à son compte. C’est pratique, mais l’utilisateur peut ensuite donner ces clés à ses amis ou collègues, voire les vendre pour des bitcoins (cela s’est effectivement produit). Les clés SSH sont en outre permanentes et restent valables jusqu’à ce qu’elles soient expressément supprimées.

Si des clés autorisées sont ajoutées pour les comptes root ou de service, elles restent facilement valables même après que la personne qui les a installées a quitté l’organisation. Elles constituent également un moyen pratique pour les pirates d’établir une présence permanente sur un système en l’absence de détection et d’alertes concernant les nouvelles clés non autorisées.

Pour ces raisons, la plupart des grandes organisations souhaitent déplacer les clés autorisées vers un emplacement appartenant à la racine et ont établi un processus contrôlé de provisionnement et de résiliation pour ces clés.

Déplacement des clés SSH vers un emplacement appartenant à la racine

En principe, le déplacement des clés SSH vers un emplacement appartenant à la racine est facile :

Créer un répertoire approprié appartenant à la racine, par exemple, /etc/ssh/keys, sous lequel les clés autorisées sont stockées.
Créer un sous-répertoire sous ce répertoire pour chaque utilisateur, et déplacer le fichier authorized_keys de chaque utilisateur vers /etc/ssh/keys/<user>/authorized_keys.
Enfin, modifiez l’ensemble AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys dans /etc/ssh/sshd_config.

En pratique, cependant, ce n’est pas toujours aussi simple, surtout dans les grands environnements. Les noms d’utilisateurs peuvent provenir d’annuaires (par exemple, Active Directory ou LDAP). De nombreuses organisations ont des versions d’OpenSSH variables, y compris des systèmes très anciens ou des constructions SSH personnalisées qui ont des chemins intégrés non standard. Nous recommandons d’utiliser des outils de gestion des clés tels que Universal SSH Key Manager pour masquer cette complexité dans les grands environnements. Ces outils peuvent également mettre en œuvre un flux de travail de provisionnement, de résiliation et d’approbation pour les clés et des alertes sur les modifications non autorisées effectuées par les utilisateurs root.

La limitation d’OpenSSH sur le nombre de clés privées

Le serveur OpenSSH a une fonctionnalité (j’appellerais cela un bug) qui consiste à compter le test pour savoir si une clé particulière peut être utilisée pour l’authentification comme une tentative d’authentification. Cela a pour conséquence que si l’utilisateur possède plus de cinq clés dans .ssh, seules certaines d’entre elles fonctionnent. Cela fait souvent échouer l’authentification par clé et est souvent difficile à comprendre pour les utilisateurs. Le moyen de contourner ce problème est de spécifier explicitement la clé privée à utiliser à l’aide de l’option -i. Une alternative consiste à ajuster la session MaxAuthTries sur le serveur, mais ce n’est pas une solution complète et il n’est pas souhaitable d’augmenter le nombre de tentatives d’authentification par mot de passe.

À quoi ressemblent les clés SSH

Une clé autorisée peut ressembler à ceci :

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar

Une clé d’identité peut ressembler à ceci :

Comment fonctionne l’authentification en SSH ?

L’initialisation d’une connexion en SSH consiste à :

Négocier la version du protocole à utiliser
Négocier les algorithmes cryptographiques et autres options à utiliser
Négocier une clé de session d’une durée d’un an.temps pour chiffrer le reste de la session
Authentification de l’hôte du serveur à l’aide de sa clé d’hôte
Authentification de l’utilisateur à l’aide d’un mot de passe, une authentification par clé publique, ou d’autres moyens.

Après cela, des données peuvent être échangées, notamment des données de terminal, des graphiques et des fichiers.

Clé SSH - Authentification à l'aide de clés SSH

Authentification par clé publique

Le mécanisme d’authentification par clé dans SSH est appelé authentification par clé publique. Essentiellement, certaines données spécifiques à la session sont signées à l’aide de la clé d’identité privée. La signature est ensuite envoyée au serveur qui vérifie si la clé utilisée pour la signature est configurée comme une clé autorisée. Le serveur vérifie ensuite la signature numérique à l’aide de la clé publique de la clé autorisée. La clé d’identité n’est jamais envoyée au serveur.

L’essentiel dans l’authentification par clé publique est qu’elle permet à un serveur d’accéder à un autre serveur sans avoir à taper un mot de passe. Cette puissante caractéristique explique pourquoi elle est si largement utilisée pour les transferts de fichiers (à l’aide du protocole SFTP) et la gestion des configurations. Il est également couramment utilisé par les administrateurs système pour l’authentification unique.

Combien les clés SSH sont courantes et quel est le risque

Les clés SSH s’avèrent être extrêmement courantes et largement utilisées. De nombreuses grandes organisations les ont accumulées pendant vingt ans sans aucun contrôle. Une entreprise typique du Fortune 500 possède plusieurs millions de clés donnant accès à ses serveurs. Dans le cas d’un client, nous avons examiné 500 applications et 15 000 serveurs, et avons trouvé 3 000 000 de clés autorisées et 750 000 paires de clés uniques. Cette organisation avait également plus de cinq millions de connexions quotidiennes utilisant des clés. Les clés étaient utilisées pour l’exécution de transactions financières, la mise à jour de configurations, le déplacement de données de journal, les transferts de fichiers, les connexions interactives des administrateurs système et bien d’autres fins.

Il s’avère que la plupart des grandes entreprises disposent de centaines de milliers, voire de millions de clés. Ces clés constituent des accès non comptabilisés et peuvent mettre en danger l’ensemble de l’entreprise.

Comment éliminer entièrement les clés SSH

Le gestionnaire d’accès à la demande PrivX peut être utilisé pour éliminer entièrement les clés SSH des serveurs et établir un contrôle d’accès et une journalisation des sessions basés sur des politiques dans toute l’entreprise. Il élimine également la plupart des charges administratives liées à la gestion des clés, tout en offrant les avantages : automatisation et authentification unique.