Sécurité
15 juillet 2022

Configurez une authentification basée sur une clé SSH sur votre serveur Linux

SSH, ou secure shell, est un protocole crypté utilisé pour administrer et communiquer avec les serveurs. Lorsque vous travaillez avec un serveur Linux, vous passez souvent une grande partie de votre temps dans une session de terminal connectée à votre serveur via SSH.

Bien qu'il existe plusieurs façons de se connecter à un serveur SSH, nous nous concentrerons dans ce guide sur la configuration des clés SSH. Les clés SSH constituent un moyen extrêmement sûr de se connecter à votre serveur. Pour cette raison, il s'agit de la méthode que nous recommandons à tous les utilisateurs.

Comment fonctionnent les clés SSH ?

Un serveur SSH peut authentifier les clients à l'aide d'une variété de méthodes différentes. La plus basique est l'authentification par mot de passe, qui est facile à utiliser, mais pas la plus sûre.

Bien que les mots de passe soient envoyés au serveur de manière sécurisée, ils ne sont généralement pas assez complexes ou longs pour résister à des attaquants répétés et persistants. La puissance de traitement moderne combinée à des scripts automatisés rend le forçage brutal d'un compte protégé par un mot de passe très possible. Bien qu'il existe d'autres méthodes pour ajouter une sécurité supplémentaire (fail2ban, etc.), les clés SSH s'avèrent être une alternative fiable et sûre.

Les paires de clés SSH sont constituées de deux clés à sécurité cryptographique. Elles sont utilisées pour authentifier un client auprès d'un serveur chiffré SSH. Chaque paire est toujours composée d'une clé publique et d'une clé privée.

La clé privée, conservée par le client, doit être maintenue rigoureusement secrète. Toute compromission de celle-ci laissera à l'attaquant l'opportunité de se connecter aux serveurs qui sont configurés avec la clé publique associée sans authentification supplémentaire. Pour assurer plus de sécurité, la clé peut être chiffrée sur le disque avec une phrase de passe.

La clé publique associée peut être partagée librement sans aucun risque, ni conséquence néfaste. La clé publique peut être utilisée pour chiffrer des messages déchiffrables seulement par la clé privée. Cette propriété est utilisée comme moyen d'identification à l'aide de la paire de clés.

La clé publique se télécharge sur un serveur distant auquel vous désirez pouvoir vous connecter avec SSH. La clé est automatiquement ajoutée à un fichier spécial : vous la trouverez dans le compte utilisateur auquel vous vous connecterez. Vous le trouverez sous le nom ~/.ssh/authorized_keys.

Lorsqu'un client tente de s'authentifier à l'aide des clés SSH, le serveur peut tester le client pour savoir s'il est en possession de la clé privée. Si le client peut prouver qu'il possède la clé privée, une session shell est créée ou la commande demandée est exécutée.

Étape 1 - Création de clés SSH

Dans un premier temps, pour configurer l'authentification par clé SSH sur votre serveur, il faut générer une paire de clés SSH sur votre ordinateur local.

Pour ce faire, nous pouvons utiliser un utilitaire spécial appelé ssh-keygen, qui est inclus dans la suite d'outils OpenSSH standard. Par défaut, il crée une paire de clés RSA de 3072 bits.

Sur votre ordinateur local, générez une paire de clés SSH en tapant :

                            ssh-keygen
                            Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):

L'utilitaire vous demandera alors de choisir un emplacement pour les clés générées. Ces clés seront, par défaut, stockées dans le répertoire ~/.ssh du répertoire personnel de votre utilisateur. La clé privée sera nommée id_rsa et la clé publique associée s'appellera id_rsa.pub.

En général, il est préférable de conserver l'emplacement par défaut à ce stade. Cela permettra à votre client SSH de trouver automatiquement vos clés SSH lors d'une tentative d'authentification. Si vous souhaitez choisir un chemin d'accès non standard, saisissez-le maintenant, sinon, appuyez sur ENTRÉE pour accepter l'emplacement par défaut.

Si vous avez précédemment généré une paire de clés SSH, vous verrez un invité de commande qui ressemble à ceci :

                            /home/username/.ssh/id_rsa already exists.
Overwrite (y/n)?

Si vous choisissez d'écraser la clé sur le disque, celle-ci ne pourra plus vous permettre de vous authentifier. Soyez très prudent en choisissant oui, car il s'agit d'un processus destructeur et irréversible.

Ensuite, vous serez invité à entrer une phrase de passe pour la clé. Il s'agit d'une phrase de passe facultative qui peut être utilisée pour chiffrer le fichier de la clé privée sur le disque.

                            Created directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Vous vous demandez peut-être quels sont les avantages d'une clé SSH si vous devez toujours saisir une phrase de passe. Voici quelques-uns de ces avantages :

  • La clé privée SSH (la partie qui peut être protégée par une phrase de passe), n'est jamais exposée sur le réseau. La phrase de passe est uniquement utilisée pour décrypter la clé sur la machine locale. Cela signifie que le forçage brut basé sur le réseau ne sera pas possible contre la phrase de passe.
  • La clé privée est gardée dans un répertoire restreint. Si les clés privées ne sont pas stockées dans un répertoire restreint, le client SSH ne les reconnaîtra pas. La clé elle-même doit également avoir des autorisations restreintes (lecture et écriture uniquement pour le propriétaire). Cela signifie que les autres utilisateurs du système ne peuvent pas fouiner.
  • Tout attaquant qui espère craquer la phrase de passe de la clé privée SSH doit déjà avoir accès au système. Ce qui veut dire qu'il aura déjà accès à votre compte utilisateur ou au compte root. Si vous êtes dans ce cas, la phrase de passe peut empêcher l'attaquant de se connecter immédiatement à vos autres serveurs. Ce qui vous laissera le temps de créer et de mettre en œuvre une nouvelle paire de clés SSH et de supprimer l'accès de la clé compromise.

Étant donné que la clé privée n'est jamais exposée au réseau et qu'elle est protégée par des autorisations de fichiers, ce fichier ne devrait jamais être accessible à quiconque autre que vous (et l'utilisateur root ). La phrase de passe sert de couche de protection supplémentaire au cas où ces conditions seraient compromises.

La phrase de passe est un ajout optionnel. Si vous en saisissez une, vous devrez la fournir chaque fois que vous utiliserez cette clé (à moins que vous n'exécutiez un logiciel d'agent SSH qui stocke la clé déchiffrée). Nous vous recommandons d'utiliser une phrase de passe, mais si vous ne souhaitez pas en définir une, vous pouvez appuyer sur ENTRÉE pour ignorer cette invite.

                            Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host
The key's randomart image is:
+--[ RSA 2048]----+
| ..o |
| E o= . |
| o. o |
| .. |
| ..S |
| o o. |
| =o.+. |
|. =++.. |
|o=++. |
+-----------------+

Vous avez maintenant une clé publique et une clé privée que vous pouvez utiliser pour vous authentifier. L'étape suivante consiste à placer la clé publique sur votre serveur afin de pouvoir utiliser l'authentification par clé SSH pour vous connecter.

Étape 2 - Copie d'une clé publique SSH sur votre serveur

Il existe plusieurs manières de télécharger votre clé publique sur votre serveur SSH distant. La méthode que vous utilisez dépend en fait des outils dont vous disposez et des détails de votre configuration actuelle.

Les méthodes suivantes sont vouées à obtenir le même résultat final, mais la plus simple et la plus automatisée est décrite en premier. Les autres techniques nécessitent toutes des étapes manuelles supplémentaires. Vous ne devez suivre ces méthodes que si vous ne pouvez pas utiliser les méthodes précédentes.

Copie de votre clé publique à l'aide de ssh-copy-id

La manière la plus simple de copier votre clé publique sur un serveur existant est d'utiliser un utilitaire nommé ssh-copy-id. Parce qu'elle est très simple, cette méthode est recommandée en priorité si elle est disponible.

L'outil ssh-copy-id est inclus dans les paquets OpenSSH de nombreuses distributions, il est donc possible qu'il soit déjà disponible sur votre système local. Pour que cette technique fonctionne, vous devez obligatoirement disposer d'un accès SSH à votre serveur par mot de passe.

Pour pouvoir vous servir de l'utilitaire, vous devez d'abord spécifier l'hôte distant auquel vous souhaitez vous connecter, ainsi que le compte utilisateur auquel vous avez un accès SSH par mot de passe. Votre clé publique SSH sera copiée sur ce compte.

La syntaxe est la suivante :

                            ssh-copy-id username@remote_host
                        

Vous pouvez voir un message similaire à celui-ci :

                            The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

Cela signifie que votre ordinateur local n'est pas en mesure de reconnaître l'hôte distant. Ce phénomène se produit la première fois que vous vous connectez à un nouvel hôte. Tapez yes et appuyez sur ENTER pour continuer.

Ensuite, l'utilitaire recherchera dans votre compte local la clé id_rsa.pub que vous avez créée précédemment. Lorsqu'il trouve la clé, il vous demande le mot de passe du compte de l'utilisateur distant :

                            /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
username@111.111.11.111's password:

Saisissez le mot de passe (pour des raisons de sécurité, la saisie ne sera pas affichée) et appuyez sur ENTRÉE. L'utilitaire se connectera au compte sur l'hôte distant en utilisant le mot de passe fourni. Ensuite, il copiera le contenu de votre clé ~/.ssh/id_rsa. pub dans un fichier du répertoire d'origine ~/.ssh du compte distant appelé authorized_keys.

Vous devriez voir une sortie ressemblant à celle-ci :

                            Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'username@111.111.11.111'"
and check to make sure that only the key(s) you wanted were added.

A ce stade, votre clé id_rsa.pub est téléchargée sur le compte distant. Vous pouvez alors passer à la section suivante.

Si vous n'avez pas de ssh-copy-id, mais que vous avez un accès SSH par mot de passe à un compte sur votre serveur, vous pouvez télécharger vos clés en utilisant une méthode SSH classique.

Nous pouvons le faire en sortant le contenu de notre clé publique SSH sur notre ordinateur local et en le faisant passer par une connexion SSH vers le serveur distant. De l'autre côté, nous pouvons nous assurer que le répertoire ~/.ssh existe sous le compte que nous utilisons et ensuite sortir le contenu que nous avons transmis dans un fichier appelé authorized_keys dans ce répertoire.

Nous utiliserons le symbole de redirection >> afin d'ajouter le contenu plutôt que de l'écraser. Cela nous permettra d'ajouter des clés sans pour autant détruire les clés qui ont été précédemment ajoutées.

La commande complète ressemblera à ceci :

                            cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
                        

Vous pouvez voir un message comme celui-ci :

                            The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

Cela signifie que votre ordinateur local ne parvient pas à reconnaître l'hôte distant. Cela se produit la première fois que vous tentez de vous connecter à un nouvel hôte. Tapez yes et appuyez sur ENTER afin de continuer.

Ensuite, vous serez invité à entrer le mot de passe associé au compte auquel vous tentez de vous connecter :

                            username@111.111.11.111's password:
                        

Après avoir tapé votre mot de passe, le contenu de votre clé id_rsa. pub sera copié à la fin du fichier authorized_keys du compte de l'utilisateur distant. Passez ensuite à la section suivante si cette opération a réussi.

Si vous ne disposez pas d'un accès SSH par mot de passe à votre serveur, vous devrez effectuer le processus ci-dessus manuellement.

Le contenu de votre fichier id_rsa.pub devra être ajouté à un fichier dans ~/.ssh/authorized_keys sur votre machine distante.

Pour afficher le contenu de votre clé id_rsa.pub, tapez ceci sur votre ordinateur local :

                            cat ~/.ssh/id_rsa.pub
                        

Vous verrez ainsi le contenu de la clé, qui pourra ressembler à quelque chose comme :

                            ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test
                        

Accédez ensuite à votre hôte distant en utilisant la méthode à votre disposition. Il peut s'agir, par exemple, d'une console Web fournie par votre fournisseur d'infrastructure.

Une fois l'accès à votre compte sur le serveur distant dévérouillé, vous devez vous assurer que le répertoire ~/.ssh est effectivement créé. Cette commande créera le répertoire si nécessaire, ou n'aura aucun effet s'il existe déjà :

                            mkdir -p ~/.ssh
                        

À ce stade, vous pouvez créer ou modifier le fichier authorized_keys dans ce répertoire. Vous pouvez ajouter le contenu de votre fichier id_rsa.pub à la fin du fichier authorized_keys, en le créant si besoin, en tapant la commande suivante :

                            echo public_key_string >> ~/.ssh/authorized_keys
                        

Dans la commande ci-dessus, vous devrez remplacer le chaîne_clé_publique par la sortie de la commande cat ~/.ssh/id_rsa.pub que vous avez exécutée sur votre système local. Elle devrait commencer par ssh-rsa AAAA... ou quelque chose de similaire.

Si cela fonctionne, vous pouvez directement passer au test de votre nouvelle authentification SSH basée sur une clé.

Étape 3 - Authentifiez-vous à votre serveur à l'aide de clés SSH

Si vous êtes parevenu à finaliser l'une des procédures ci-dessus, vous devriez pouvoir vous connecter à l'hôte distant sans entrer le mot de passe du compte distant.

Le processus est quasiment le même :

                            ssh username@remote_host
                        

En cas de première connexion à cet hôte (si vous avez utilisé la dernière méthode ci-dessus), vous pouvez voir un message comme celui-ci :

                            The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

Cela veut dire que votre ordinateur local ne peut pas reconnaître l'hôte distant. Entrez yes, puis appuyez sur ENTER pour continuer.

Dans le cas où vous n'avez pas fourni de phrase de passe pour votre clé privée, votre connexion se fera automatiquement. Si vous avez fourni une phrase de passe pour la clé privée lorsque vous avez créé celle-ci, c'est là que vous devrez la saisir. Ensuite, une nouvelle session shell sera créée pour vous avec le compte du système distant.

Si vous réussissez, continuez afin de savoir comment verrouiller le serveur.

Étape 4 - Désactiver l'authentification par mot de passe sur votre serveur

Si vous êtes parvenu à vous connecter à votre compte à l'aide de SSH sans mot de passe, c'est que vous avez configuré avec succès l'authentification par clé SSH pour votre compte. Cependant soyez vigilant, car votre mécanisme d'authentification par mot de passe est toujours actif. En d'autre termes, votre serveur est toujours exposé aux attaques par force brute.

Avant de suivre les étapes de cette section, assurez-vous que l'authentification par clé SSH est bien configurée pour le compte root sur ce serveur, ou idéalement, que l'authentification par clé SSH est configurée pour un compte sur ce serveur avec un accès sudo. Cette étape permettra de verrouiller les connexions basées sur un mot de passe. Il est donc primordial de s'assurer que vous serez toujours en capacité d'obtenir un accès administratif.

Une fois les conditions ci-dessus réunies, connectez-vous à votre serveur distant avec des clés SSH, soit en tant que root, soit avec un compte disposant des privilèges sudo. Ouvrez ensuite le fichier de configuration du démon SSH :

                            sudo nano /etc/ssh/sshd_config
                        

Dans ce fichier, recherchez une directive appelée PasswordAuthentication. Elle peut être commentée. Décommentez la ligne en supprimant tout # en début de ligne, puis mettez la valeur à no. Cette action permettra de désactiver votre capacité à vous connecter via SSH en utilisant les mots de passe associés au compte :

/etc/ssh/sshd_config

                            PasswordAuthentication no
                        

Pensez à auvegarder puis fermez le fichier dès que vous avez terminé. Enfin, pour mettre en œuvre les changements qui viennent d'être effectués, il sera impératif de redémarrer le service.

Sur la plupart des distributions Linux, il suffira de lancer la commande suivante pour le faire :

                            sudo systemctl restart ssh
                        

Après avoir terminé cette ultime étape, vous êtes parvenu à faire en sorte que votre démon SSH ne réponde qu'aux clés SSH.

Conclusion

L'authentification basée sur les clés SSH est désormais configurée et fonctionne sur votre serveur. Cette nouvelle configuration vous permet de vous connecter à votre serveur sans fournir le mot de passe du compte, et offre ainsi une meilleure sécurité.