Authentification basée sur des clés dans OpenSSH pour Windows

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows 10 et (build 1809 et ultérieure)

La plupart des authentifications dans les environnements Windows se font avec une paire nom d’utilisateur/mot de passe, ce qui fonctionne bien pour les systèmes qui partagent un domaine commun. Si vous travaillez sur plusieurs domaines, par exemple sur un système local et un système hébergé dans le cloud, ceux-ci deviennent vulnérables aux intrusions par force brute.

À titre de comparaison, les environnements Linux utilisent généralement des paires de clés publiques ou privées pour gérer une authentification qui ne demande pas d’utiliser des mots de passe pouvant être devinés. OpenSSH inclut des outils pour aider à prendre en charge l’authentification basée sur les clés, notamment :

  • ssh-keygen pour la génération de clés sécurisées
  • ssh-agent et ssh-add pour le stockage sécurisé des clés privées
  • scp et sftp pour copier en toute sécurité des fichiers de clé publique lors de l’utilisation initiale d’un serveur

Ce document fournit une vue d’ensemble de l’utilisation de ces outils sur Windows pour commencer à utiliser l’authentification basée sur clé avec SSH. Si vous n’êtes pas familier avec la gestion des clés SSH, nous vous recommandons vivement de consulter le document NIST IR 7966 intitulé « Security of Interactive and Automated Access Management Using Secure Shell (SSH) ».

À propos des paires de clés

Les paires de clés font référence aux fichiers de clé publique et privée utilisés par certains protocoles d’authentification.

L’authentification par clé publique SSH utilise des algorithmes de chiffrement asymétriques pour générer deux fichiers de clé : un « privé » et l’autre « public ». Les fichiers de clé privée sont l’équivalent d’un mot de passe et doivent demeurer protégés en toutes circonstances. Si quelqu’un détient votre clé privée, il peut se connecter en votre nom à n’importe quel serveur SSH auquel vous avez accès. La clé publique est placée sur le serveur SSH et peut être partagée sans compromettre la clé privée.

L’authentification basée sur une clé autorise le serveur et le client SSH à comparer la clé publique d’un nom d’utilisateur fourni avec la clé privée. Si la clé publique côté serveur ne peut pas être validée par rapport à la clé privée côté client, l’authentification échoue.

L’authentification multifacteur peut être implémentée avec des paires de clés en entrant une phrase secrète quand la paire de clés est générée (voir Génération d’une clé utilisateur ci-dessous). L’utilisateur est invité à entrer la phrase secrète pendant l’authentification. La phrase secrète est utilisée en plus de la clé privée sur le client SSH pour authentifier l’utilisateur.

Important

Une session distante ouverte via l’authentification basée sur des clés n’a pas d’informations d’identification utilisateur associées et n’est donc pas capable d’authentification sortante en tant qu’utilisateur, c’est par conception.

Génération d’une clé d’hôte

Les clés publiques ont des exigences de liste de contrôle d’accès spécifiques qui, sur Windows, équivalent à ne permettre l’accès qu’aux administrateurs et au système. Lors de la première utilisation de sshd, la paire de clés de l’hôte sera générée automatiquement.

Important

OpenSSH Server doit être installé en premier. Consultez Bien démarrer avec OpenSSH.

Par défaut, le service sshd est défini pour démarrer manuellement. Pour le démarrer chaque fois que le serveur est redémarré, exécutez les commandes suivantes à partir d’une invite PowerShell avec élévation de privilèges sur votre serveur :

# Set the sshd service to be started automatically
Get-Service -Name sshd | Set-Service -StartupType Automatic

# Now start the sshd service
Start-Service sshd

Étant donné qu’aucun utilisateur n’est associé au service sshd, les clés de l’hôte sont stockées sous C:\ProgramData\ssh.

Génération d’une clé utilisateur

Pour utiliser l’authentification par clé, vous devez d’abord générer des paires de clés publiques/privées pour votre client. ssh-keygen.exe est utilisé pour générer des fichiers de clés et les algorithmes DSA, RSA, ECDSA ou Ed25519 peuvent être spécifiés. Si aucun algorithme n’est spécifié, RSA est utilisé. Un algorithme et une longueur de clé forts doivent être utilisés, comme Ed25519 dans cet exemple.

Pour générer des fichiers de clé avec l’algorithme Ed25519, exécutez la commande suivante à partir d’une invite PowerShell ou cmd sur votre client :

ssh-keygen -t ed25519

La sortie de la commande devrait afficher le résultat suivant (où « username » est remplacé par votre nom d’utilisateur) :

Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\username/.ssh/id_ed25519):

Vous pouvez appuyer sur Entrée pour accepter la valeur par défaut ou indiquer un chemin et/ou un nom de fichier où vous aimeriez que vos clés soient générées. À ce stade, vous serez invité à utiliser une phrase secrète pour chiffrer vos fichiers de clé privée. La phrase secrète peut être vide, mais elle n’est pas recommandée. La phrase secrète fonctionne avec le fichier de clé pour fournir une authentification à deux facteurs. Pour cet exemple, nous laissons la phrase secrète vide.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\username/.ssh/id_ed25519.
Your public key has been saved in C:\Users\username/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:OIzc1yE7joL2Bzy8!gS0j8eGK7bYaH1FmF3sDuMeSj8 username@LOCAL-HOSTNAME

The key's randomart image is:
+--[ED25519 256]--+
|        .        |
|         o       |
|    . + + .      |
|   o B * = .     |
|   o= B S .      |
|   .=B O o       |
|  + =+% o        |
| *oo.O.E         |
|+.o+=o. .        |
+----[SHA256]-----+

Vous avez maintenant une paire de clés publique/privée ed25519 à l’emplacement spécifié. Les fichiers .pub sont des clés publiques, tandis que les fichiers sans extension sont des clés privées :

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         6/3/2021   2:55 PM            464 id_ed25519
-a----         6/3/2021   2:55 PM            103 id_ed25519.pub

Rappelez-vous que les fichiers de clés privées sont l’équivalent d’un mot de passe et que vous devez les protéger de la même manière que votre mot de passe. Utilisez ssh-agent pour stocker en toute sécurité les clés privées dans un contexte de sécurité Windows associé à votre compte Windows. Pour démarrer le service ssh-agent chaque fois que votre ordinateur est redémarré, et utilisez ssh-add pour stocker la clé privée, exécutez les commandes suivantes à partir d’une invite PowerShell avec élévation de privilèges sur votre serveur :

# By default the ssh-agent service is disabled. Configure it to start automatically.
# Make sure you're running as an Administrator.
Get-Service ssh-agent | Set-Service -StartupType Automatic

# Start the service
Start-Service ssh-agent

# This should return a status of Running
Get-Service ssh-agent

# Now load your key files into ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Une fois que vous avez ajouté la clé à l’agent ssh sur votre client, l’agent ssh récupère automatiquement la clé privée locale et la transmet à votre client SSH.

Important

Il est fortement recommandé de sauvegarder votre clé privée dans un emplacement sécurisé, puis de la supprimer du système local après l’avoir ajoutée à ssh-agent. La clé privée ne peut pas être récupérée auprès de l’agent si un algorithme fort a été utilisé, tel que Ed25519 dans cet exemple. Si vous perdez l’accès à la clé privée, vous devrez créer une nouvelle paire de clés et mettre à jour la clé publique sur tous les systèmes avec lesquels vous interagissez.

Déploiement de la clé publique

Pour utiliser la clé d’utilisateur créée ci-dessus, le contenu de votre clé publique (\.ssh\id_ed25519.pub) doit être placé sur le serveur dans un fichier texte. Le nom et l’emplacement du fichier varient selon que le compte d’utilisateur est membre du groupe administrateurs local ou d’un compte d’utilisateur standard. Les sections suivantes couvrent les utilisateurs standard et administratifs.

Utilisateur standard

Le contenu de votre clé publique (.ssh\id_ed25519.pub) doit être placé sur le serveur dans un fichier texte appelé authorized_keys dans C:\Users\username.ssh. Vous pouvez copier votre clé publique à l’aide de l’utilitaire de transfert de fichiers sécurisé OpenSSH scp ou à l’aide d’une commande PowerShell pour écrire la clé dans le fichier.

L’exemple ci-dessous copie la clé publique sur le serveur (où « username » est remplacé par votre nom d’utilisateur). Vous devrez utiliser le mot de passe du compte d’utilisateur pour le serveur au départ.

# Get the public key file generated previously on your client
$authorizedKey = Get-Content -Path $env:USERPROFILE\.ssh\id_ed25519.pub

# Generate the PowerShell to be run remote that will copy the public key file generated previously on your client to the authorized_keys file on your server
$remotePowershell = "powershell New-Item -Force -ItemType Directory -Path $env:USERPROFILE\.ssh; Add-Content -Force -Path $env:USERPROFILE\.ssh\authorized_keys -Value '$authorizedKey'"

# Connect to your server and run the PowerShell using the $remotePowerShell variable
ssh username@domain1@contoso.com $remotePowershell

Utilisateur administratif

Le contenu de votre clé publique (.ssh\id_ed25519.pub) doit être placé sur le serveur dans un fichier texte appelé administrators_authorized_keys dans C:\ProgramData\ssh. Vous pouvez copier votre clé publique à l’aide de l’utilitaire de transfert de fichiers sécurisé OpenSSH scp ou à l’aide d’une commande PowerShell pour écrire la clé dans le fichier. La liste de contrôle d’accès de ce fichier doit être configurée pour autoriser uniquement l’accès aux administrateurs et au système.

L’exemple ci-dessous copie la clé publique sur le serveur et configure la liste de contrôle d’accès (où « username » est remplacé par votre nom d’utilisateur). Vous devrez utiliser le mot de passe du compte d’utilisateur pour le serveur au départ.

Remarque

Cet exemple montre les étapes pour créer le fichier administrators_authorized_keys. Cela ne s’applique qu’aux comptes d’administrateur et doit être utilisé à la place du fichier utilisateur dans l’emplacement du profil utilisateur.

# Get the public key file generated previously on your client
$authorizedKey = Get-Content -Path $env:USERPROFILE\.ssh\id_ed25519.pub

# Generate the PowerShell to be run remote that will copy the public key file generated previously on your client to the authorized_keys file on your server
$remotePowershell = "powershell Add-Content -Force -Path $env:ProgramData\ssh\administrators_authorized_keys -Value '''$authorizedKey''';icacls.exe ""$env:ProgramData\ssh\administrators_authorized_keys"" /inheritance:r /grant ""Administrators:F"" /grant ""SYSTEM:F"""

# Connect to your server and run the PowerShell using the $remotePowerShell variable
ssh username@domain1@contoso.com $remotePowershell

Pour les versions localisées du système d'exploitation qui ne sont pas en anglais, le script devra être modifié pour refléter les noms de groupes en conséquence. Pour éviter les erreurs lors de l'octroi de permissions aux noms de groupes, l'identifiant de sécurité (SID) peut être utilisé à la place. Le SID peut être récupéré en exécutant Get-LocalGroup | Select-Object Name, SID Lorsque vous utilisez le SID à la place du nom du groupe, il doit être précédé d'un astérisque (*). Dans l'exemple suivant, le groupe Administrateurs utilise le SID suivant S-1-5-32-544:

$remotePowershell = "powershell Add-Content -Force -Path $env:ProgramData\ssh\administrators_authorized_keys -Value '''$authorizedKey''';icacls.exe ""$env:ProgramData\ssh\administrators_authorized_keys"" /inheritance:r /grant ""*S-1-5-32-544:F"" /grant ""SYSTEM:F"""

Ces étapes terminent la configuration requise pour utiliser l’authentification basée sur clé avec OpenSSH sur Windows. Une fois que les commandes PowerShell ont été exécutées, l’utilisateur peut se connecter à l’hôte sshd à partir de n’importe quel client disposant de la clé privée.