Administration : créez de meilleures clés SSH avec ssh-keygen

Pourquoi générer des clés SSH ?

SSH peut être utilisé sans échange préalable de paires de clés publiques et ces utilisations peuvent être raisonnablement sûres. La meilleure approche pour authentifier les sessions SSH en toute sécurité consiste toutefois à créer une paire de clés publiques pour l’ordinateur local et à copier le fichier de clés publiques sur le serveur SSH distant.

Seul un utilisateur disposant d’une autorisation authentifiée doit pouvoir copier des fichiers sur le serveur. Si les utilisateurs locaux ne disposent pas d’autorisations suffisantes, ils peuvent demander à un administrateur système de l’hôte distant de copier les fichiers pour eux.

Le fait de placer un fichier de clé publique sur un serveur SSH permet à l’utilisateur associé à la clé publique de se connecter en toute sécurité au serveur SSH. Pour ce faire, les utilisateurs doivent authentifier leur propriété de la clé publique en démontrant qu’ils contrôlent la clé privée de la paire de clés publiques.

Cet article aborde trois cas d’utilisation :

• Configurer un serveur SSH pour qu’il reconnaisse le client SSH en copiant le fichier de clé publique de l’ordinateur local de l’utilisateur vers le serveur distant.
• Copier le fichier de clé publique d’un seul utilisateur sur plusieurs serveurs distants. Cela permet à l’utilisateur d’accéder à distance à plusieurs systèmes via SSH, en utilisant le même identifiant de connexion. C’est particulièrement utile pour les administrateurs système qui effectuent une maintenance à distance de plusieurs systèmes, par exemple.
• Copier sur un serveur distant plusieurs clés publiques associées à différents comptes d’utilisateurs, chacun disposant de différents niveaux d’autorisation. Dans ce cas, l’utilisateur utilise une clé publique pour s’authentifier lorsqu’il se connecte à des sessions d’émulation de terminal avec le serveur distant et une autre clé publique avec des autorisations plus élevées pour effectuer l’administration du système.

Les procédures décrites dans cet article s’appliquent de préférence aux clients et aux serveurs individuels et démontrent comment les clés SSH peuvent être générées et utilisées. Les systèmes de gestion centralisée des clés sont préférables pour une utilisation plus générale dans les grandes entreprises où de nombreux utilisateurs différents doivent être accrédités pour accéder à de nombreux serveurs différents. Ces systèmes de gestion des clés sont toutefois capables d’automatiser les processus expliqués ici.

Comment fonctionne SSH ?

SSH repose sur l’authentification par clé publique pour négocier une connexion sécurisée entre un client SSH et un serveur SSH. SSH est souvent utilisé pour établir une connexion ad hoc entre le client et le serveur distant sans qu’une paire de clés publiques ait été créée au préalable, par exemple avec une commande comme celle-ci :

PS C:\Users\peter\.ssh> ssh 192.0.2.44 -l peter

Dans ce cas, la commande ssh, émise à l’invite de commande Windows PowerShell, comprend l’adresse IP du serveur distant et l’option -l, qui spécifie un compte d’utilisateur valide sur le serveur distant. Une fois la connexion SSH établie, les utilisateurs sont invités à saisir le mot de passe de leur compte d’utilisateur, dans ce cas, le mot de passe de l’utilisateur peter.

Dans cet exemple, le client et le serveur ne peuvent pas encore s’authentifier l’un l’autre à l’aide de clés publiques, c’est pourquoi l’utilisateur est invité à saisir son mot de passe :

The authenticity of host '192.0.2.44' can't be established.

Cette invite est suivie de la signature numérique du serveur et d’une invite pour poursuivre la connexion. La signature numérique est un hachage sécurisé de la clé publique du serveur, qui est stockée dans un fichier du répertoire SSH. Sur les systèmes Linux et macOS, l’emplacement par défaut des clés SSH se trouve dans le répertoire personnel de l’utilisateur, dans le fichier ~/.ssh/known_hosts. Sur les systèmes Windows, l’emplacement par défaut du fichier se trouve dans le répertoire personnel de l’utilisateur, dans le fichier C:\Users\username\.ssh\known_hosts.

Dans cet exemple, une connexion SSH est établie entre le client SSH et le serveur SSH sur le même hôte en utilisant l’adresse de bouclage, 127.0.0.1. Cette adresse est souvent utilisée à des fins de test et dirige tout le trafic réseau vers les logiciels client et serveur fonctionnant sur l’ordinateur local. La connexion client par défaut dans cet exemple utilise une clé ECDSA (Elliptic Curve Digital Signature Algorithm).

Une bonne pratique de sécurité pour SSH prévoit que l’utilisateur copie cette signature numérique et l’authentifie par rapport à la clé publique du serveur distant. Dans la pratique, cette étape est souvent ignorée lorsque l’utilisateur est certain que le serveur distant est un serveur de confiance. Une fois que l’utilisateur accepte l’authenticité du serveur distant, ce serveur et sa signature numérique sont ajoutés au fichier des hôtes connus et les connexions ultérieures peuvent être établies directement.

Cette approche ad hoc peut être suffisamment sûre lorsque l’utilisateur se connecte à un serveur à l’intérieur d’un réseau protégé, mais elle peut s’avérer plus risquée pour la connexion à d’autres serveurs distants. C’est là que ssh-keygen peut rationaliser l’échange d’authentification par clé publique.

Générer une nouvelle clé SSH

La commande ssh-keygen est un composant de la plupart des implémentations SSH utilisé pour générer une paire de clés publiques à utiliser lors de l’authentification avec un serveur distant. En règle générale, les utilisateurs génèrent une nouvelle clé publique, puis la copient sur le serveur à l’aide de SSH et de leurs identifiants de connexion au serveur distant.

Par défaut, ssh-keygen crée une paire de clés RSA et stocke la clé publique dans un fichier de clés publiques nommé .ssh/id_rsa.pub et un fichier de clés privées nommé .ssh/id_rsa.

La génération des clés commence par la commande suivante :

$ ssh-keygen -t rsa

Dans cet exemple de base, ssh-keygen est invoqué pour générer une nouvelle paire de clés SSH à l’aide de l’algorithme de clé publique RSA.

Cette capture d’écran montre ce qui se passe lorsque la commande ssh-keygen est exécutée avec l’option -t pour spécifier une clé RSA. La commande ssh-keygen effectue alors les opérations suivantes :

• Elle génère une paire de clés publiques.
• En réponse à l’invite « Enter passphrase », l’utilisateur peut entrer un mot de passe pour protéger l’accès à la clé privée. L’utilisation d’un mot de passe renforce la sécurité et est recommandée pour les applications sensibles. Si une clé n’est pas protégée par un mot de passe, un pirate qui obtient l’accès au système de l’utilisateur obtiendrait également un accès direct à des systèmes distants éventuellement sensibles. Dans certains cas, il peut être acceptable d’appuyer sur Entrée pour ne pas utiliser de mot de passe en réponse à cette invite.
• La clé privée, également connue sous le nom d’identification, est stockée dans un fichier nommé id_rsa dans le répertoire .ssh du répertoire personnel de l’utilisateur (HOME$/ sous Windows et ~/ sous Linux et autres systèmes d’exploitation Unix).
• La clé publique est enregistrée dans un fichier portant le même nom que la clé privée, mais avec l’extension .pub, produisant un fichier nommé pub dans le même répertoire.
• La signature de la clé est créée et affichée. La signature est une courte séquence d’octets générée par une fonction de hachage cryptographique appliquée à la clé générée. Les implémentations SSH peuvent utiliser les signatures pour authentifier la clé publique. La signature numérique comprend tous les commentaires appliqués à la paire de clés. La signature identifie également l’algorithme de hachage utilisé pour créer la clé publique. Dans ce cas, il s’agit de l’algorithme Secure Hash Algorithm 256, ou SHA-256, avec un condensé composé de 256 bits.
• Une image « randomart » aléatoire est affichée. Il s’agit d’une image composée de caractères ASCII choisis selon les données de la signature numérique de la clé. L’image randomart de la clé est destinée à permettre aux humains de déterminer visuellement si les signatures numériques de différents serveurs sont identiques ou non. Les bits de la signature numérique sont traités comme des instructions pour un algorithme qui produit l’image randomart.

La commande ssh-keygen crée deux fichiers, l’un public et l’autre privé, pour l’ordinateur local. Dans ce cas, les deux fichiers sont :

• id-rsa, qui contient la clé privée de la paire. Ce fichier ne doit jamais être partagé ou copié sur un système distant, sauf s’il s’agit d’un système contrôlé par le détenteur de la paire de clés.
• id-rsa.pub, qui contient la clé publique de la paire. Ce fichier peut être partagé et copié sur d’autres systèmes, en particulier lorsque l’utilisateur prévoit de se connecter à ces systèmes à l’aide de SSH.

Le nom de fichier des autres types de clés utilise, par défaut, la forme ~/.ssh/id_[type de clé].  Ainsi, les noms de fichier par défaut pour chaque type de clé sont les suivants :

La copie du fichier de clé publique sur un serveur – ou sur plusieurs serveurs – est l’étape suivante pour obtenir une authentification forte automatique lors de la connexion à des serveurs SSH distants.

Copier une clé publique sur un serveur

L’étape suivante pour rationaliser le processus de connexion consiste à copier la clé publique nouvellement générée par l’utilisateur depuis le système local de l’utilisateur vers le serveur SSH distant. Lorsque les deux systèmes utilisent l’implémentation OpenSSH sur un système d’exploitation Unix, y compris Linux ou macOS, la commande ssh-copy-id peut être utilisée pour installer une clé SSH en tant que clé de connexion autorisée. La nouvelle clé publique est ensuite ajoutée au fichier authorized_keys, que le SSH exécuté sur le serveur distant vérifie lorsqu’une connexion est demandée à l’ordinateur local. Par exemple :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]/home/peter/.ssh/authorized_keys

Dans cet exemple, le fichier de clés publiques est copié dans le fichier authorized_keys.

Toutefois, la commande ssh-copy-id n’est pas toujours disponible, par exemple lorsque l’on travaille avec des systèmes Windows. Pour copier une clé publique sur un serveur à partir d’une ligne de commande PowerShell, utilisez la commande suivante :

PS c:> type $env:USERPROFILE\.ssh\id_rsa.pub | ssh [email protected] "cat >> .ssh/authorized_keys"

Cette commande composée utilise la commande type de PowerShell pour afficher le contenu du fichier de clé publique. Le contenu est ensuite transféré à l’aide du symbole | vers une nouvelle connexion SSH. La dernière section citée de cette commande utilise la commande cat sur le serveur distant pour ajouter le nouveau fichier de clé publique à la fin du fichier authorized_keys. Cette partie de la commande est nécessaire pour éviter d’écraser le fichier authorized_keys, ce qui aurait pour effet d’écraser toutes les clés existantes ajoutées précédemment à ce fichier.

Désormais, la clé publique réside sur le serveur distant et est stockée dans le fichier .ssh/authorized_keys. La prochaine fois qu’une connexion SSH est tentée à partir de l’ordinateur local, la session est lancée sans qu’il soit nécessaire de saisir manuellement l’identifiant et le mot de passe de l’utilisateur.

La possibilité de se connecter à un serveur SSH sur un serveur distant sans avoir à ressaisir son mot de passe à chaque fois peut s’avérer pratique, mais ce n’est pas la principale raison d’utiliser une clé publique pour l’authentification SSH. Lorsque les connexions SSH peuvent être établies sans que l’utilisateur ait à saisir de mot de passe, des actions répétitives sur le serveur distant peuvent être accomplies sans intervention humaine. Par exemple :

• Incorporer des connexions SSH dans des fichiers batch ou des scripts Shell pour automatiser des actions répétitives, comme la copie de fichiers journaux ou l’accès à des serveurs de messagerie distants.
• Programmer des actions répétitives qui nécessitent une authentification, mais qui se produisent lorsque l’ordinateur local est sans surveillance.
• Offrir un confort aux utilisateurs, ce qui ne doit pas être négligé, car une authentification par clé publique avec SSH correctement mise en œuvre peut être plus sûre que d’obliger les utilisateurs à utiliser des mots de passe compliqués pour des systèmes auxquels ils n’accèdent que rarement.

L’authentification par clé publique avec SSH n’est pas suffisante pour sécuriser l’accès aux systèmes sensibles. Bien qu’elle puisse améliorer la sécurité, les utilisateurs et les entreprises doivent prendre encore plus de précautions pour empêcher tout accès non autorisé aux ordinateurs locaux utilisés afin d’accéder aux serveurs SSH distants.

Copier une clé publique sur plusieurs serveurs

Les administrateurs système, les gestionnaires de réseau et les professionnels de la sécurité réseau qui utilisent le même identifiant de connexion sur un réseau d’entreprise ont souvent besoin de se connecter à de nombreux serveurs distants différents. Dans les grandes entreprises, ce type d’accès peut être facilité par l’utilisation de systèmes de gestion de clés SSH capables de distribuer des clés publiques aux serveurs distants et de gérer l’attribution de paires de clés publiques aux personnes qui en ont besoin.

Dans la pratique, les administrateurs système peuvent copier manuellement la même clé publique sur tous les serveurs auxquels ils ont besoin d’accéder. Dans ce cas, l’administrateur système envoie la même commande pour copier la clé publique de chaque serveur distant. Par exemple :

PS c:> type $env:USERPROFILE\.ssh\id_rsa.pub | ssh [email protected] "cat >> .ssh/authorized_keys"

Cette commande peut être utilisée dans PowerShell pour envoyer le fichier de clé publique id_rsa.pub afin d’associer la clé publique à l’ID utilisateur peter sur le serveur dont le nom d’hôte est ssh.example.org.

Copie de plusieurs clés publiques sur un serveur

Les professionnels des réseaux et de la sécurité peuvent avoir besoin d’utiliser différentes identités, chacune disposant de différents ensembles d’autorisations, pour accéder au même serveur distant. Cette approche compartimente l’accès et peut s’avérer utile pour différentes raisons, notamment les suivantes :

• Pour respecter le principe du moindre privilège, plusieurs paires de clés publiques peuvent être attribuées à des identités qui ont différents niveaux de privilèges sur un système pour différentes fonctions. Une paire de clés peut être utilisée pour donner un accès limité à des fins de test, tandis qu’une autre paire de clés peut être utilisée pour obtenir un accès administratif au système afin de gérer les comptes d’utilisateurs.
• Cette approche permet de suivre les différentes fonctions exécutées par le même utilisateur. Par exemple, un informaticien peut utiliser différentes clés publiques lorsqu’il travaille pour différents clients internes.

Lors de l’ajout de plusieurs clés publiques au même serveur distant, les noms des fichiers de clés publiques sont différents et doivent être spécifiés lors de l’exécution de la commande ssh. Par exemple :

$ ssh -i ~/.ssh/id_Alice [email protected]

Cette commande utilise l’option -i pour spécifier un fichier d’identité, ~/.ssh/id_Alice, que l’hôte distant doit utiliser pour authentifier la connexion..