Configuration du serveur OpenSSH pour Windows Server et Windows

  • Article

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

Cet article traite de la configuration propre à Windows pour le serveur OpenSSH (sshd).

OpenSSH gère la documentation détaillée des options de configuration en ligne sur OpenSSH.com, qui n’est pas dupliquée dans cet ensemble de documentation.

Fichiers de configuration OpenSSH

OpenSSH a des fichiers de configuration pour les paramètres serveur et client. OpenSSH est open source, et est ajouté aux systèmes d’exploitation de serveur Windows et de client Windows à compter de Windows Server 2019 et Windows 10 (build 1809). Par conséquent, la documentation open source pour les fichiers de configuration OpenSSH n’est pas répétée ici. Les fichiers de configuration du client se trouvent dans la page de manuel ssh_config. Les fichiers de configuration du serveur OpenSSH se trouvent quant à eux dans la page de manuel sshd_config.

Le serveur OpenSSH (sshd) lit les données de configuration à partir de %programdata%\ssh\sshd_config par défaut. Un autre fichier de configuration peut être spécifié en lançant sshd.exe avec le paramètre -f. En cas d’absence du fichier, sshd en génère un avec la configuration par défaut lorsque le service est démarré.

Dans Windows, le client OpenSSH (ssh) lit les données de configuration à partir d’un fichier de configuration dans l’ordre suivant :

  1. En lançant ssh.exe avec le paramètre -F, en spécifiant le chemin d’un fichier de configuration et un nom d’entrée à partir de ce fichier
  2. Le fichier de configuration d’un utilisateur dans %userprofile%\.ssh\config
  3. Le fichier de configuration à l’échelle du système dans %programdata%\ssh\ssh_config

Configuration du shell par défaut pour OpenSSH dans Windows

L’interface shell par défaut offre une expérience utilisateur à toute personne se connectant au serveur à l’aide de SSH. Par défaut, le Windows initial est l’interface shell Windows (cmd.exe). Windows comprend également PowerShell. Des interpréteurs de commandes tiers sont par ailleurs disponibles pour Windows et peuvent être configurées comme shell par défaut pour un serveur.

Pour définir l’interface shell par défaut, vérifiez d’abord que le dossier d’installation de OpenSSH se trouve sur le chemin d’accès système. Pour Windows, le dossier d’installation par défaut est %systemdrive%\Windows\System32\openssh. La commande suivante montre le paramètre du chemin actuel, et y ajoute le dossier d’installation OpenSSH par défaut.

Interface shell Commande à utiliser
Commande path
PowerShell $env:path

La configuration de l’interpréteur de commandes ssh par défaut s’effectue dans le Registre Windows en ajoutant le chemin complet de l’exécutable de l’interpréteur de commandes à HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH dans la valeur de chaîne DefaultShell.

Par exemple, la commande PowerShell avec élévation de privilèges suivante définit le shell par défaut comme étant powershell.exe :

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

Configurations de Windows dans sshd_config

Dans Windows, sshd lit les données de configuration à partir de %programdata%\ssh\sshd_config par défaut. Un autre fichier de configuration peut être spécifié en lançant sshd.exe avec le paramètre -f. En cas d’absence du fichier, sshd en génère un avec la configuration par défaut lorsque le service est démarré.

Les éléments listés ci-dessous fournissent une configuration spécifique à Windows possible par le biais d’entrées dans sshd_config. D’autres paramètres de configuration sont possibles, mais ils ne sont pas listés ici car ils sont abordés en détail dans la documentation en ligne Win32 OpenSSH.

Conseil

Le serveur OpenSSH (sshd) lit le fichier de configuration lors du démarrage du service. Toute modification apportée au fichier de configuration nécessite le redémarrage du service.

AllowGroups, AllowUsers, DenyGroups, DenyUsers

Le contrôle des utilisateurs et des groupes qui peuvent se connecter au serveur se fait à l’aide des directives AllowGroups, AllowUsers, DenyGroups et DenyUsers. Les directives d’autorisation/refus sont traitées dans l’ordre suivant : DenyUsers, AllowUsers, DenyGroups et enfin AllowGroups. Tous les noms de compte doivent être indiqués en minuscules. Pour plus d’informations sur les modèles et les caractères génériques dans le fichier ssh_config, consultez la page de manuel sshd_config OpenBSD.

Lorsque vous configurez des règles basées sur des utilisateurs ou des groupes avec un utilisateur ou un groupe de domaines, utilisez le format suivant : user?domain*. Windows autorise l’utilisation de plusieurs formats afin d’indiquer les principes du domaine, mais beaucoup d’entre eux entrent en conflit avec les modèles Linux standard. Pour cette raison, * est ajouté pour inclure les noms de domaine complets. En outre, cette approche utilise « ? », au lieu de @, pour éviter les conflits avec le format nom_utilisateur@hôte.

Les utilisateurs de groupes de travail/groupes de travail et les comptes connectés à Internet sont toujours résolus avec leur nom de compte local (sans composant de domaine, comme pour les noms UNIX standard). Les utilisateurs et les groupes de domaine sont strictement résolus au format NameSamCompatible – domain_short_name\user_name. Toutes les règles de configuration basées sur les utilisateurs et les groupes doivent respecter ce format.

L’exemple suivant refuse contoso\admin de l’hôte 192.168.2.23, et bloque tous les utilisateurs du domaine contoso. Il autorise également les utilisateurs qui sont membres des groupes contoso\sshusers et contoso\serveroperators.

DenyUsers contoso\admin@192.168.2.23
DenyUsers contoso\*
AllowGroups contoso\sshusers contoso\serveroperators

L’exemple ci-dessous autorise l’utilisateur localusers à se connecter à partir de l’hôte 192.168.2.23, et autorise les membres du groupe sshusers.

AllowUsers localuser@192.168.2.23
AllowGroups sshusers

AuthenticationMethods

Pour OpenSSH Windows, les seules méthodes d’authentification disponibles sont password et publickey.

Important

L'authentification à l'aide d'un compte Microsoft Entra n'est actuellement pas prise en charge.

AuthorizedKeysFile

Par défaut, il s’agit de .ssh/authorized_keys. Si le chemin n’est pas absolu, il est pris par rapport au répertoire de base de l’utilisateur (ou au chemin de l’image de profil), par exemple C:\Users\nom_utilisateur. Si l’utilisateur appartient au groupe d’administrateurs, %programdata%/ssh/administrators_authorized_keys est utilisé à la place.

Conseil

Le fichier administrators_authorized_keys doit uniquement avoir des entrées d’autorisation pour le compte NT Authority\SYSTEM et le groupe de sécurité BUILTIN\Administrateurs. Un contrôle total doit être accordé au compte NT Authority\SYSTEM. Le groupe de sécurité BUILTIN\Administrateurs est requis pour que les administrateurs gèrent les clés autorisées. Vous pouvez choisir l’accès requis. Pour accorder des autorisations, vous pouvez ouvrir une invite PowerShell avec élévation de privilèges et exécuter la commande icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F".

ChrootDirectory (prise en charge ajoutée dans v7.7.0.0)

Cette directive est uniquement prise en charge avec les sessions SFTP. Une session à distance dans cmd.exe ne respecterait pas le ChrootDirectory. Pour configurer un serveur chroot avec SFTP uniquement, définissez ForceCommand SFTP interne. Vous pouvez également configurer SCP avec chroot, en implémentant un shell personnalisé qui autorise uniquement SCP et SFTP.

GSSAPIAuthentication

L’argument de configuration GSSAPIAuthentication spécifie si l’authentification utilisateur basée sur GSSAPI est autorisée. La valeur par défaut de GSSAPIAuthentication est non.

L’authentification GSSAPI nécessite également l’utilisation du commutateur -K spécifiant le nom d’hôte lors de l’utilisation du client OpenSSH. En guise d’alternative, vous pouvez créer une entrée correspondante dans la configuration du client SSH. Dans Windows, le client OpenSSH lit les données de configuration à partir de %userprofile%.ssh\config par défaut.

Vous pouvez voir un exemple de configuration du client GSSAPI OpenSSH ci-dessous.

# Specify a set of configuration arguments for a host matching the pattern SERVER01.contoso.com
# Patterns are case sensitive
Host SERVER01.contoso.com
    # Enables GSSAPI authentication
    GSSAPIAuthentication yes
    # Forward (delegate) credentials to the server.
    GSSAPIDelegateCredentials yes

Important

GSSAPI est disponible uniquement à partir de Windows Server 2022, Windows 11 et Windows 10 xxxx.

HostKey

Les valeurs par défaut sont :

#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key

Si les valeurs par défaut ne sont pas présentes, sshd les génère automatiquement lors du démarrage du service.

Correspond

Établit une correspondance avec des conditions à l’aide d’un ou plusieurs critères. En cas de correspondance, les arguments de configuration suivants sont appliqués. Les correspondances utilisent les règles de modèle couvertes dans la section AllowGroups, AllowUsers, DenyGroups, DenyUsers. Les noms d’utilisateur et de groupe doivent être en minuscules.

PermitRootLogin

Non applicable dans Windows. Pour empêcher la connexion de l’administrateur, utilisez Administrateurs avec la directive DenyGroups.

SyslogFacility

Si vous avez besoin d’une journalisation basée sur des fichiers, utilisez LOCAL0. Les journaux sont générés sous %programdata%\ssh\logs. Pour toute autre valeur, y compris la valeur par défaut, AUTH dirige la journalisation vers ETW. Pour plus d’informations, consultez les fonctionnalités de journalisation dans Windows.

Arguments de configuration

L’argument de configuration suivant est disponible à partir de Windows Server 2022, Windows 11 et Windows 10 xxxx :

  • GSSAPIAuthentication

Les arguments de configuration suivants ne sont pas disponibles dans la version OpenSSH fournie avec Windows Server et le client Windows :

  • AcceptEnv
  • AllowStreamLocalForwarding
  • AuthorizedKeysCommand
  • AuthorizedKeysCommandUser
  • AuthorizedPrincipalsCommand
  • AuthorizedPrincipalsCommandUser
  • ExposeAuthInfo
  • GSSAPICleanupCredentials
  • GSSAPIStrictAcceptorCheck
  • HostbasedAcceptedKeyTypes
  • HostbasedAuthentication
  • HostbasedUsesNameFromPacketOnly
  • IgnoreRhosts
  • IgnoreUserKnownHosts
  • KbdInteractiveAuthentication
  • KerberosAuthentication
  • KerberosGetAFSToken
  • KerberosOrLocalPasswd
  • KerberosTicketCleanup
  • PermitTunnel
  • PermitUserEnvironment
  • PermitUserRC
  • PidFile
  • PrintLastLog
  • PrintMotd
  • RDomain
  • StreamLocalBindMask
  • StreamLocalBindUnlink
  • StrictModes
  • X11DisplayOffset
  • X11Forwarding
  • X11UseLocalhost
  • XAuthLocation