Comment configurer l'authentification basée sur une clé SSH sur un serveur Linux

De Get Docs
Aller à :navigation, rechercher

Introduction

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

Bien qu'il existe différentes manières de se connecter à un serveur SSH, dans ce guide, nous nous concentrerons sur la configuration des clés SSH. Les clés SSH offrent un moyen extrêmement sécurisé de se connecter à votre serveur. Pour cette raison, c'est la méthode que nous recommandons à tous les utilisateurs.

Comment fonctionnent les clés SSH ?

Un serveur SSH peut authentifier les clients à l'aide de différentes méthodes. La plus basique d'entre elles est l'authentification par mot de passe, qui est facile à utiliser, mais pas la plus sécurisée.

Bien que les mots de passe soient envoyés au serveur de manière sécurisée, ils ne sont généralement pas suffisamment complexes ou longs pour résister aux attaques répétées et persistantes. La puissance de traitement moderne combinée à des scripts automatisés rend très possible le forçage brutal d'un compte protégé par mot de passe. 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écurisée.

Les paires de clés SSH sont deux clés cryptographiquement sécurisées qui peuvent être utilisées pour authentifier un client auprès d'un serveur SSH. Chaque paire de clés est constituée d'une clé publique et d'une clé privée.

La clé privée est conservée par le client et doit être gardée absolument secrète. Toute compromission de la clé privée permettra à l'attaquant de se connecter aux serveurs configurés avec la clé publique associée sans authentification supplémentaire. Comme précaution supplémentaire, la clé peut être chiffrée sur disque avec une phrase de passe.

La clé publique associée peut être partagée librement sans aucune conséquence négative. La clé publique peut être utilisée pour chiffrer des messages que seule la clé privée peut déchiffrer. Cette propriété est utilisée comme moyen d'authentification à l'aide de la paire de clés.

La clé publique est téléchargée sur un serveur distant auquel vous souhaitez pouvoir vous connecter avec SSH. La clé est ajoutée à un fichier spécial dans le compte d'utilisateur auquel vous vous connecterez appelé ~/.ssh/authorized_keys.

Lorsqu'un client tente de s'authentifier à l'aide de 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 générée ou la commande demandée est exécutée.

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

La première étape pour configurer l'authentification par clé SSH sur votre serveur consiste à 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 avec la suite d'outils OpenSSH standard. Par défaut, cela créera 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
OutputGenerating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):

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

Habituellement, il est préférable de s'en tenir à l'emplacement par défaut à ce stade. Cela permettra à votre client SSH de trouver automatiquement vos clés SSH lors de la tentative d'authentification. Si vous souhaitez choisir un chemin non standard, saisissez-le maintenant, sinon appuyez sur ENTER pour accepter la valeur par défaut.

Si vous aviez précédemment généré une paire de clés SSH, vous pouvez voir une invite qui ressemble à ceci :

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

Si vous choisissez d'écraser la clé sur le disque, vous ne pourrez plus vous authentifier avec la clé précédente. Soyez très prudent lorsque vous sélectionnez oui, car il s'agit d'un processus destructeur qui ne peut pas être inversé.

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

Ensuite, vous serez invité à saisir 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 clé privée sur le disque.

Vous vous demandez peut-être quels avantages offre une clé SSH si vous devez toujours saisir une phrase de passe. Certains des avantages sont :

  • La clé SSH privée (la partie qui peut être protégée par une phrase secrète) n'est jamais exposée sur le réseau. La phrase de passe est uniquement utilisée pour déchiffrer la clé sur la machine locale. Cela signifie que le forçage brutal basé sur le réseau ne sera pas possible contre la phrase de passe.
  • La clé privée est conservée dans un répertoire restreint. Le client SSH ne reconnaîtra pas les clés privées qui ne sont pas conservées dans des répertoires restreints. La clé elle-même doit également avoir des autorisations restreintes (lecture et écriture uniquement disponibles pour le propriétaire). Cela signifie que les autres utilisateurs du système ne peuvent pas espionner.
  • Tout attaquant espérant déchiffrer la phrase secrète de la clé SSH privée doit déjà avoir accès au système. Cela signifie qu'ils auront déjà accès à votre compte utilisateur ou au compte root. Si vous êtes dans cette position, la phrase secrète peut empêcher l'attaquant de se connecter immédiatement à vos autres serveurs. Cela vous donnera, espérons-le, le temps de créer et d'implémenter une nouvelle paire de clés SSH et de supprimer l'accès à la clé compromise.

Étant donné que la clé privée n'est jamais exposée au réseau et est protégée par des autorisations de fichiers, ce fichier ne doit jamais être accessible à quiconque d'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.

Une phrase de passe est un ajout facultatif. Si vous en saisissez une, vous devrez la fournir à chaque fois que vous utiliserez cette clé (sauf si vous exécutez un logiciel agent SSH qui stocke la clé déchiffrée). Nous vous recommandons d'utiliser une phrase secrète, mais si vous ne souhaitez pas définir de phrase secrète, vous pouvez appuyer sur ENTER pour contourner cette invite.

OutputYour 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:
SHA256:CAjsV9M/tt5skazroTc1ZRGCBz+kGtYUIPhRvvZJYBs [email protected]
The key's randomart image is:
+---[RSA 3072]----+
|o   ..oo.++o ..  |
| o o +o.o.+...   |
|. . + oE.o.o  .  |
| . . oo.B+  .o   |
|  .   .=S.+ +    |
|      . o..*     |
|        .+= o    |
|        .=.+     |
|       .oo+      |
+----[SHA256]-----+

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

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

Remarque : une version précédente de ce didacticiel contenait des instructions pour ajouter une clé publique SSH à votre compte DigitalOcean. Ces instructions se trouvent désormais dans la section Clés SSH de notre documentation produit DigitalOcean.


Il existe plusieurs façons de télécharger votre clé publique sur votre serveur SSH distant. La méthode que vous utilisez dépend en grande partie des outils dont vous disposez et des détails de votre configuration actuelle.

Les méthodes suivantes donnent toutes le même résultat final. La méthode la plus simple et la plus automatisée est décrite en premier, et celles qui suivent nécessitent chacune des étapes manuelles supplémentaires. Vous ne devez les suivre que si vous ne parvenez pas à utiliser les méthodes précédentes.

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

Le moyen le plus simple de copier votre clé publique sur un serveur existant consiste à utiliser un utilitaire appelé ssh-copy-id. En raison de sa simplicité, cette méthode est recommandée si elle est disponible.

L'outil ssh-copy-id est inclus dans les packages OpenSSH dans de nombreuses distributions, vous pouvez donc déjà l'avoir disponible sur votre système local. Pour que cette méthode fonctionne, vous devez actuellement disposer d'un accès SSH basé sur un mot de passe à votre serveur.

Pour utiliser l'utilitaire, vous devez spécifier l'hôte distant auquel vous souhaitez vous connecter et le compte d'utilisateur auquel vous avez un accès SSH basé sur un mot de passe. Il s'agit du compte sur lequel votre clé SSH publique sera copiée.

La syntaxe est :

ssh-copy-id [email protected]_host

Vous pouvez voir un message comme celui-ci :

OutputThe 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 ne reconnaît pas l'hôte distant. Cela se produira la première fois que vous vous connecterez à un nouvel hôte. Tapez yes et appuyez sur ENTER pour continuer.

Ensuite, l'utilitaire analysera votre compte local pour la clé id_rsa.pub que nous avons créée précédemment. Lorsqu'il trouve la clé, il vous demandera le mot de passe du compte de l'utilisateur distant :

Output/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
[email protected]'s password:

Tapez le mot de passe (votre saisie ne sera pas affichée pour des raisons de sécurité) et appuyez sur ENTER. L'utilitaire se connectera au compte sur l'hôte distant à l'aide du mot de passe que vous avez fourni. Il copiera ensuite le contenu de votre clé ~/.ssh/id_rsa.pub dans un fichier du répertoire d'accueil ~/.ssh du compte distant appelé authorized_keys.

Vous verrez une sortie qui ressemble à ceci :

OutputNumber of key(s) added: 1

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

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

Copier votre clé publique à l'aide de SSH

Si vous ne disposez pas de ssh-copy-id, mais que vous disposez d'un accès SSH basé sur un mot de passe à un compte sur votre serveur, vous pouvez télécharger vos clés à l'aide d'une méthode SSH conventionnelle.

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

Nous utiliserons le symbole de redirection >> pour ajouter le contenu au lieu de l'écraser. Cela nous permettra d'ajouter des clés sans détruire les clés précédemment ajoutées.

La commande complète ressemblera à ceci :

cat ~/.ssh/id_rsa.pub | ssh [email protected]_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Vous pouvez voir un message comme celui-ci :

OutputThe 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 ne reconnaît pas l'hôte distant. Cela se produira la première fois que vous vous connecterez à un nouvel hôte. Tapez yes et appuyez sur ENTER pour continuer.

Ensuite, vous serez invité à saisir le mot de passe du compte auquel vous tentez de vous connecter :

[email protected]'s password:

Après saisie de 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 à la section suivante si cela a réussi.

Copie manuelle de votre clé publique

Si vous ne disposez pas d'un accès SSH basé sur un 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 sur ~/.ssh/authorized_keys sur votre machine distante d'une manière ou d'une autre.

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

cat ~/.ssh/id_rsa.pub

Vous verrez le contenu de la clé, qui peut ressembler à ceci :

~/.ssh/id_rsa.pub

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

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

Remarque : si vous utilisez un droplet DigitalOcean, veuillez vous reporter à notre documentation de la console de récupération dans la documentation du produit DigitalOcean.


Une fois que vous avez accès à votre compte sur le serveur distant, vous devez vous assurer que le répertoire ~/.ssh est créé. Cette commande créera le répertoire si nécessaire, ou ne fera rien s'il existe déjà :

mkdir -p ~/.ssh

Maintenant, 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 nécessaire, en utilisant ceci :

echo public_key_string >> ~/.ssh/authorized_keys

Dans la commande ci-dessus, remplacez public_key_string par la sortie de la commande cat ~/.ssh/id_rsa.pub que vous avez exécutée sur votre système local. Il doit commencer par ssh-rsa AAAA... ou similaire.

Si cela fonctionne, vous pouvez continuer à tester votre nouvelle authentification SSH basée sur une clé.

Étape 3 - Authentification sur votre serveur à l'aide de clés SSH

Si vous avez réussi l'une des procédures ci-dessus, vous devriez pouvoir vous connecter à l'hôte distant sans le mot de passe du compte distant.

Le processus est essentiellement le même :

ssh [email protected]_host

Si c'est la première fois que vous vous connectez à cet hôte (si vous avez utilisé la dernière méthode ci-dessus), vous pouvez voir quelque chose comme ceci :

OutputThe 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 ne reconnaît pas l'hôte distant. Tapez yes puis appuyez sur ENTER pour continuer.

Si vous n'avez pas fourni de phrase secrète pour votre clé privée, vous serez immédiatement connecté. Si vous avez fourni une phrase de passe pour la clé privée lors de la création de la clé, vous devrez la saisir maintenant. Ensuite, une nouvelle session shell sera créée pour vous avec le compte sur le système distant.

En cas de succès, continuez pour savoir comment verrouiller le serveur.

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

Si vous avez pu vous connecter à votre compte en utilisant SSH sans mot de passe, vous avez configuré avec succès l'authentification basée sur la clé SSH pour votre compte. Cependant, votre mécanisme d'authentification par mot de passe est toujours actif, ce qui signifie que votre serveur est toujours exposé aux attaques par force brute.

Avant de suivre les étapes de cette section, assurez-vous que l'authentification basée sur la clé SSH est configurée pour le compte racine sur ce serveur ou, de préférence, que l'authentification basée sur la clé SSH est configurée pour un compte sur ce serveur avec un accès sudo. Cette étape verrouillera les connexions basées sur un mot de passe, il est donc essentiel de s'assurer que vous pourrez toujours obtenir un accès administratif.

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

sudo nano /etc/ssh/sshd_config

Dans le fichier, recherchez une directive appelée PasswordAuthentication. Cela peut être commenté. Décommentez la ligne en supprimant tout # au début de la ligne et définissez la valeur sur no. Cela désactivera votre capacité à vous connecter via SSH à l'aide de mots de passe de compte :

/etc/ssh/sshd_config

PasswordAuthentication no

Enregistrez et fermez le fichier lorsque vous avez terminé. Pour réellement mettre en œuvre les modifications que nous venons d'apporter, vous devez redémarrer le service.

Sur la plupart des distributions Linux, vous pouvez exécuter la commande suivante pour cela :

sudo systemctl restart ssh

Après avoir terminé cette étape, vous avez réussi la transition de votre démon SSH pour ne répondre qu'aux clés SSH.

Conclusion

Vous devriez maintenant avoir une authentification basée sur une clé SSH configurée et en cours d'exécution sur votre serveur, vous permettant de vous connecter sans fournir de mot de passe de compte. De là, vous pouvez vous diriger dans de nombreuses directions. Si vous souhaitez en savoir plus sur l'utilisation de SSH, consultez notre Guide des bases de SSH.