Utiliser l’accès distant SSH

Depuis Windows Server 2019, Microsoft a introduit la prise en charge d’OpenSSH Server à ses systèmes d’exploitation. Ceci est aussi vrai pour Windows 10 (depuis v1809) et Windows 11.

Au sein de Windows Server 2025, le serveur OpenSSH présente la particularité d’être déjà installé, bien qu’il ne soit pas activé par défaut. Après un rapide rappel sur le SSH, nous verrons comment activer et utiliser cette fonctionnalité.

I. Le protocole SSH

Le protocole SSH (Secure Shell) est un protocole de communication à distance, qui présente l’avantage d’être sécurisé car les flux entre le client et le serveur sont chiffrés. Son implémentation la plus connue est OpenSSH, et c’est elle que Microsoft a décidé d’implémenter sur Windows.

Il est très populaire sur les systèmes Linux et Unix, bien qu’il soit aussi utilisé pour l’administration d’équipements réseau (routeur, commutateur, etc.). Par défaut, le serveur SSH est en écoute sur le port 22 et la connexion s’appuie sur le protocole TCP.

Il prend en charge de nombreuses options de configuration, notamment l’authentification par mot de passe et l’authentification par clé SSH. Pour ce second mode d’authentification, plus sécurisé, des clés asymétriques sont utilisées, il y a donc une clé publique et une clé privée.

La prise en charge de SSH sur Windows est assez récente. Jusqu’ici, pour se connecter à distance en ligne de commande à un serveur, il était nécessaire d’utiliser le protocole WinRM. Il reste toujours pris en charge et il est activé par défaut, contrairement à SSH.

II. Activer le serveur SSH

Pour activer le serveur SSH, et donc l’accès SSH, sur Windows Server 2025, vous avez deux méthodes possibles :

• L’interface graphique avec le « Gestionnaire de serveur »
• La ligne de commande avec PowerShell

A partir de l’interface graphique, vous n’avez qu’à cliquer sur le lien nommé « Désactivé » sur la ligne « Accès SSH distant ». Ceci va ouvrir une console PowerShell : la configuration sera alors effectuée automatiquement, c’est-à-dire le lancement du service avec configuration en démarrage automatique et paramétrage du pare-feu Windows Defender. Parfois, rien ne se passe ou une erreur est renvoyée, ce qui nous contraint à passer par la méthode manuelle.

Pour effectuer la configuration avec PowerShell, ouvrez une console en tant qu’administrateur (via un clic droit) et suivez les instructions suivantes.

Démarrez le service OpenSSH Server (sshd) sur la machine (par défaut en démarrage manuel) :

Start-Service sshd

A partir de là, le serveur SSH est actif et en écoute sur le port 22. Si vous souhaitez qu’il démarre automatiquement, même après le redémarrage du serveur, exécutez ceci :

Set-Service -Name sshd -StartupType 'Automatic'

Une règle de pare-feu nommée « OpenSSH Server (sshd) » est existante sur Windows Server. Elle autorise les connexions entrantes sur le port 22/TCP, correspondant au SSH. A titre d’information, voici la commande PowerShell qui permettrait de créer cette règle :

New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Cette règle autorise le flux entrant uniquement sur le profil « Privé » du pare-feu Windows Defender.  Cela signifie que si la machine est connectée à un domaine Active Directory, il ne sera pas possible de se connecter en SSH.

Remarque : avec PowerShell, il est possible d’ajouter le paramètre « -Profile » pour spécifier les profils ciblés dès la création de la règle.

III. Autoriser l’accès SSH en domaine

Pour le moment, nous n’avons pas encore évoqué le rôle d’un Active Directory, mais si votre machine est connectée à un domaine, vous devrez ajuster la règle de pare-feu.

A partir de la console de configuration du pare-feu Windows Defender, vous pourrez localiser la règle « OpenSSH SSH Server (sshd) » dans les règles de trafic entrant.

Vous devez modifier cette règle et cliquer sur l’onglet « Avancé » afin de cocher le profil « Domaine ».

Vous pouvez aussi éditer la règle avec PowerShell :

Set-NetFirewallRule -DisplayName 'OpenSSH SSH Server (sshd)' -Profile Domain, Private

IV. Le groupe de sécurité « Utilisateurs OpenSSH »

Par défaut, les administrateurs du serveur peuvent se connecter à distance via le protocole SSH. En complément, un groupe de sécurité nommé « Utilisateurs OpenSSH » est disponible : chaque membre de ce groupe peut accéder en SSH au serveur. Par exemple, un utilisateur standard qui n’est pas administrateur du serveur peut se connecter en SSH, s’il est membre de ce groupe.

Cette configuration est définie dans le fichier « sshd_config » situé dans le répertoire suivant :

• C:\ProgramData\ssh

La directive « AllowGroups » sert à spécifier les groupes de sécurité autorisés à se connecter. La valeur par défaut est la suivante :

AllowGroups administrators "openssh users" 

Néanmoins, si votre serveur est en français, vous devez adapter la configuration, car le groupe ne s’appelle pas « openssh users » mais « Utilisateurs OpenSSH ». Adaptez la ligne :

AllowGroups administrators "Utilisateurs OpenSSH"

Enregistrez le fichier et redémarrez le service « sshd » avec la console « Services » ou PowerShell :

Restart-Service sshd

V. Se connecter en SSH à Windows

Notre machine Windows Server 2025 dispose d’un serveur OpenSSH actif et prêt à l’emploi. Désormais, nous allons tenter une connexion à distance.

J’utilise une machine Windows 11, où le client SSH est préinstallé par défaut. Vous pouvez utiliser une machine sous Windows, Linux ou macOS, la seule condition étant d’avoir un client SSH. Il peut aussi s’agir d’une application tierce telle que PuTTY.

Pour utiliser le client OpenSSH sur Windows, ouvrez une console PowerShell. Ensuite, saisissez la commande suivante :

ssh [email protected]

Ici, nous supposons que l’hôte distant sur lequel le SSH est activé dispose de l’adresse IP « 192.168.10.211 » et que nous utilisons le compte « Administrateur » pour nous connecter.

La première fois, il sera nécessaire de valider la tentative de connexion en écrivant « Yes » suivi d’un appui sur la touche « Entrée ». Ensuite, le mot de passe de l’utilisateur sera demandé.

S’il est correct et que ce compte est autorisé à se connecter, la connexion sera établie et un shell s’affichera à l’écran. Ce shell contient un prompt constitué du nom du compte connecté, ici « administrateur@SRV-WS2025 » et de l’emplacement dans lequel on se situe sur la machine distante.

Si vous exécutez la commande « hostname » dans cette console, le nom du serveur distant auquel vous êtes connecté doit s’afficher.

De plus, à partir cette session distante, si vous souhaitez administrer la machine en ligne de commande avec PowerShell, vous devez basculer dans PowerShell via :

powershell.exe

Sinon, à partir du prompt actuel, vous avez accès aux commandes MS-DOS (ping, dir, etc.). Pour quitter la session distante, saisissez simplement (par deux fois si vous avez basculé dans PowerShell) :

exit

VI. Modifier le port d’écoute de SSH

Pour rappel, la configuration du serveur OpenSSH est définie dans le fichier « sshd_config » du répertoire « C:\ProgramData\ssh ». Ce fichier regroupe des directives similaires à celles que nous pouvons retrouver avec OpenSSH sur Linux.

Pour modifier le port d'écoute par défaut (action recommandée) et utiliser un autre port que le port 22, vous devez modifier l'option « Port ». Afin de déterminer le port « 222 », il convient de remplacer :

#Port 22

Par ceci :

Port 222

Le fait de supprimer le caractère « # » permet « d’activer » la directive, car sinon elle est commentée. Ensuite, enregistrez le fichier et redémarrez le service SSH.

Restart-Service sshd

En complément, vous devez modifier la règle de pare-feu Windows Defender pour autoriser le SSH sur le port 222 à la place du port 22.

Set-NetFirewallRule -DisplayName 'OpenSSH SSH Server (sshd)' -LocalPort 222

Pour se connecter à ce serveur, il sera nécessaire de préciser le numéro de port lors d’une connexion SSH. Voici un exemple :

ssh [email protected] -p 222

Désormais, la connexion SSH doit être établie sur le port 222/TCP. Cette modification est intéressante pour « masquer » le service SSH du serveur et réduire les risques de tentatives de connexions infructueuses.

VII. Utiliser PowerShell comme shell SSH

En modifiant la configuration d’OpenSSH à partir du Registre Windows, vous pouvez définir PowerShell comme shell par défaut. Cela signifie que lors d’une connexion au serveur, vous aurez directement accès à la console PowerShell.

Vous devez créer et configurer la valeur de Registre nommée « DefaultShell » et spécifier le chemin vers l’exécutable de PowerShell. Pour effectuer cette configuration via PowerShell, exécutez la commande suivante :

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force

Cette modification est prise en compte immédiatement. Vous pouvez utiliser l’éditeur de Registre (regedit.exe), si vous préférez. Dans les deux cas, le résultat obtenu est identique.

Pour approfondir aller plus loin dans la configuration d’OpenSSH Server, voici le lien vers la documentation Microsoft :

• Microsoft Learn - Configuration OpenSSH Server

VIII. Configurer l’authentification par clé SSH

Par défaut, l’authentification SSH est effectuée à partir d’un nom d’utilisateur et d’un mot de passe. Il s’agit du mode d’authentification traditionnel, mais qui est vulnérable aux attaques par brute force. Pour renforcer la sécurité de l’accès SSH, il est recommandé de mettre en place l’authentification par clé SSH.

A partir de notre poste de travail d’administrateur système, nous allons générer une paire de clés SSH. Nous obtiendrons deux fichiers : une clé privée et une clé publique. La clé privée est sensible : elle doit être sauvegardée en lieu sûr et ne pas être partagée (sur le principe d’un mot de passe, à titre de comparaison). A l’inverse, la clé publique associée à notre clé privée devra être « copiée » sur tous les serveurs auxquels nous souhaitons nous connecter.

Ainsi, il sera possible de s’authentifier sur les serveurs grâce à la clé privée, sans avoir à préciser un nom d’utilisateur ou un mot de passe. Dans cet exemple, la machine « W11-01 » sera utilisée comme poste de travail source et nous essaierons de nous connecter au serveur « SRV-WS2025 » (il s’agit du serveur utilisé depuis le début de ce chapitre).

L’utilisateur « Florian » du poste de travail devra pouvoir se connecter en tant qu’administrateur au serveur Windows Server.

A. Générer une paire de clés SSH

Depuis la session de l’utilisateur « Florian », sur le poste de travail, la première étape consiste à générer une paire de clés en utilisant l’algorithme ECDSA (plusieurs choix sont possibles).

ssh-keygen -t ecdsa

Suite à l’exécution de la commande, il est demandé de choisir un emplacement pour stocker les clés. Appuyez sur Entrée sans effectuer de modification. Par défaut, les clés seront stockées dans le profil de l’utilisateur, dans un sous-répertoire nommé « .ssh » (comme sur Linux).

Ensuite, vous devez définir une passphrase pour protéger la clé privée. Il est recommandé de définir un mot de passe robuste, que vous pourrez stocker dans votre coffre-fort de mots de passe.

Finalement, vous obtenez deux fichiers :

• id_ecdsa : ce fichier sans extension correspond à la clé privée
• id_ecdsa.pub : ce fichier correspond à la clé publique

Sur ma machine, ils sont situés dans « C:\Users\Florian\.ssh ».

Vous pouvez accéder à ce répertoire ou lister son contenu avec PowerShell pour vérifier la présence de ces deux fichiers.

Get-ChildItem "C:\Users\Florian\.ssh"

B. Configurer ssh-agent sur Windows

OpenSSH est livré avec plusieurs outils, dont « ssh-agent ». Nous pouvons l’utiliser pour stocker les clés privées de façon sécurisée et l’accès sera lié au compte Windows.

Nous allons devoir démarrer et configurer ce service et charger la nouvelle clé privée dans ssh-agent. Voici les commandes à exécuter.

Commencez par configurer le service en démarrage automatique :

Get-Service ssh-agent | Set-Service -StartupType Automatic

Puis, démarrez le service :

Start-Service ssh-agent

Enfin, chargez la clé privée dans ssh-agent (via le profil de l’utilisateur actuel) :

ssh-add $env:USERPROFILE\.ssh\id_ecdsa

Désormais, l'agent SSH est capable de récupérer automatiquement la clé privée et la transmettre au client SSH lors d’une connexion à un serveur.

C. Copier et autoriser la clé publique avec scp

La clé publique de notre utilisateur doit être copiée sur le serveur distant, à savoir « SRV-WS2025 ». Dans le cadre de son utilisation sur Windows, OpenSSH s’appuie deux fichiers pour stocker les clés publiques autorisées :

• authorized_keys dans le profil de l’utilisateur, pour les utilisateurs standards
  • Par exemple : C:\Users\Utilisateur-Serveur\.ssh\authorized_keys
• administrators_authorized_keys dans ProgramData  pour les accès administrateurs.
  • Par exemple : C:\ProgramData\ssh\administrators_authorized_keys

Ces fichiers sont déclarés dans le fichier de configuration du serveur SSH. Dans les deux cas, la clé publique doit être copiée sur la machine distante, seul le fichier cible pourra changer en fonction des besoins.

Afin de pouvoir nous connecter en tant qu’administrateur sur le serveur distant, nous allons copier le fichier « id_ecdsa.pub » en tant que « administrators_authorized_keys », via SCP. Cet outil, inclut à OpenSSH, permet de transférer des fichiers via SSH.

Remarque : un fichier d’autorisation peut contenir plusieurs clés publiques. Il faut concaténer les clés publiques dans un même fichier. Ici, nous partons de zéro, donc nous créons le fichier avec le contenu de notre clé publique.

Nous utilisons l’accès par identifiant et mot de passe pour copier le fichier à l’emplacement souhaité. L’option « -P » doit être utilisée pour spécifier un port spécifique (non utile pour le port 22). Voici la commande :

scp -P 222 "C:\Users\Florian\.ssh\id_ecdsa.pub" [email protected]:C:\ProgramData\ssh\administrators_authorized_keys

Le fichier a bien été copié sur le serveur distant.

Ce fichier étant associé aux accès administrateurs, il est sensible. Nous allons modifier ses permissions pour qu’il soit accessible uniquement aux Administrateurs et au Système.

Vous pouvez vous connecter en SSH, en mode interactif, pour exécuter la commande ci-dessous ou passer directement sur le serveur distant. A vous de voir. Nous utiliserons l’outil « icacls.exe », intégré à Windows, il sert à modifier les permissions en mode console.

icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrateurs:F" /grant "SYSTEM:F"

Remarque : si vous utilisez un serveur en anglais, le groupe « Administrateurs » s’appelle « Administrators » donc la commande doit être adaptée.

Il nous reste une dernière étape à effectuer avant de tester la configuration.

D. Autoriser l’authentification par clé SSH

Par défaut, seule l’authentification par mot de passe est autorisée dans le serveur SSH de Windows. Nous devons éditer le fichier « sshd_config » pour activer l’authentification basée sur une clé.

Décommentez la ligne suivante (et veillez à ce qu’elle soit sur « yes ») :

PubkeyAuthentication yes

Comme ceci :

Par la suite, quand l’accès par clé SSH sera opérationnel, vous pourrez désactiver l’authentification par mot de passe en configuration la directive « PasswordAuthentication » de cette façon :

PasswordAuthentication no

Après chaque modification du fichier de configuration, enregistrez et à redémarrez le service :

Restart-Service sshd

Désormais, il ne reste plus qu’à tester.

E. Se connecter avec une clé SSH sur Windows

À partir de l’ordinateur « W11-01 » et de la session « Florian », nous allons tenter d’initier une connexion par clé SSH à destination de « SRV-WS2025 ». Indiquez simplement ceci :

ssh [email protected] -p 222

La session distante devrait s’ouvrir automatiquement ! Si vous n’avez pas eu besoin de saisir la passphrase de votre clé privée, c’est grâce à la configuration de l’agent-ssh. En effet, l’utilisateur « Florian » est autorisé à accéder à cette clé privée grâce à son compte Windows.

Sans cette action, la passphrase de la clé privée serait demandée de cette façon :

Remarque : vous pouvez spécifier le chemin vers une clé privée via l’option « -i ».

Si vous désactivez l’authentification par mot de passe et qu’un utilisateur tente de se connecter de cette façon, il sera rejeté :

[email protected]: Permission denied (publickey,keyboard-interactive).

La connexion distante fonctionne, il m’est possible d’administrer le serveur via SSH.

IX. Les journaux du serveur SSH de Windows

Le serveur OpenSSH de Windows utilise un journal accessible à partir de l’Observateur d’événements. Il est situé à cet emplacement :

• Journaux des applications et des services > OpenSSH > Operational

Il contient l’historique des connexions réussies, en échecs, mais aussi les changements d’état du serveur SSH. Voici un exemple d’événement créé suite à une authentification par clé SSH réussie.

Il y a bien un répertoire « logs » dans « C:\ProgramData\ssh » mais il est vide.

Bien que n’ayons pas exploré l’ensemble des fonctionnalités du serveur SSH de Windows, vous disposez d’une base solide pour configurer cet accès sur un ou plusieurs serveurs. L’authentification par clé SSH est à prioriser, en comparaison de l’habituel mot de passe.