Configuration d'OpenSSH pour Windows en utilisant l'authentification par clé publique

Question

J'ai des problèmes pour configurer OpenSSH pour Windows, en utilisant l'authentification par clé publique.

Je l'ai fait fonctionner sur mon bureau local et je peux utiliser une clé pour accéder à des machines Unix ou d'autres machines OpenSSH pour Windows.

J'ai répliqué le build sur un serveur, l'authentification par mot de passe fonctionne bien, mais lorsque j'utilise les clés, j'obtiens le problème suivant :

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /cygdrive/c/sshusers/jsadmint2232/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Connection closed by 127.0.0.1

Ainsi, pour les besoins du test, j'ai simplement essayé de SSH à localhost, mais même lorsque j'ai essayé à distance, j'ai eu le même problème.

Ce qui est encore plus étrange, c'est que lorsque le mot de passe et la clé publique sont tous deux activés dans l'application sshd_config il n'essaiera d'utiliser que les clés, puis le message ci-dessus et n'essaiera même pas d'utiliser le mot de passe.

Voici les mesures que j'ai prises :

1. Installer OpenSSH pour Windows
2. mkgroup -l >>..\etc\group (ajout de groupes locaux)
3. mkgroup -d >>..\etc\group (ajout de groupes de domaines)
4. mkpasswd -L -u openssh >>..\passwd (ajout de mon utilisateur local)
5. mkpasswd -D -u jsadmint2232 >>..\passwd (ajout de l'utilisateur de mon domaine)
6. Modifié le homedir dans le fichier passwd pour pointer vers c : \sshusers %USER% - où %USER% est le nom de l'utilisateur
7. Activation de l'authentification par mot de passe, désactivation de l'authentification par clé
8. Création de clés SSH pour jsadmint2232 / OpenSSH et vérification que les fichiers ont été créés dans les répertoires personnels.
9. Ajout des fichiers authorized_keys dans les répertoires .ssh pour chaque utilisateur et ajout des clés pour les utilisateurs qui se connectent.
10. net stop opensshd / net start opensshd
11. Testez si l'authentification par mot de passe fonctionne à la fois localement et à distance.
12. Mise à jour de sshd_config, pour activer l'authentification par clé - redémarrer opensshd
13. Tester la connexion et obtenir l'erreur ci-dessus. En outre, il ne tente même pas l'authentification par mot de passe.
14. Mise à jour de sshd_config, pour désactiver complètement l'authentification par mot de passe - redémarrer opensshd
15. Test de connexion et toujours l'erreur ci-dessus

Il semble que le serveur coupe la connexion pour une raison quelconque.

Answer 1

Je l'ai résolu en :

1. Installation en mode SSHD_SERVER + séparation des privilèges. J'ai également défini manuellement la séparation des privilèges sur "oui" dans la configuration. Cela n'a pas fonctionné pour moi pendant un bon moment, l'utilisateur n'a pas été créé. Puis cela a fonctionné, je ne sais pas pourquoi. Je suis seulement allé dans les comptes d'utilisateurs dans le panneau de configuration pour vérifier que l'UAC est désactivé. J'avais également /var/empty avec un accès complet pour tout le monde.
2. Pour C:\openssh\var\empty J'ai défini les permissions "attributs get/set" à Everyone et myself et les permissions "full" à . \sshd_server. J'en ai aussi fait le propriétaire.

Answer 2

La solution de n0rd est bonne mais il y a une complication supplémentaire pour les utilisateurs qui sont également dans le groupe de l'administrateur. Si vous recherchez une solution à une situation impliquant les conditions suivantes :

• Vous voulez utiliser les clés publiques sur une base par utilisateur (ou vous ne voulez pas utiliser l'outil de gestion des clés publiques). administrators_authorized_keys ).
• Et vous Ne le fais pas. voulez utiliser PasswordAuthentication.
• Et certains de ces utilisateurs appartiennent également au groupe des administrateurs.

Le problème que j'ai rencontré est que lorsque j'ai essayé la solution de n0rd, elle n'a pas fonctionné pour les utilisateurs dans les conditions ci-dessus. Après quelques bricolages, j'ai trouvé une solution qui fonctionne systématiquement pour moi. Suivez la solution de n0rd et modifiez simplement les éléments suivants

Dans le ssh_config assurez-vous que les paramètres suivants sont définis :

AuthorizedKeysFile  .ssh/authorized_keys 
PasswordAuthentication no
PubkeyAuthentication yes

Veillez également à mettre en commentaire le paramètre " Match Group Administrators " :

#Match Group administrators
#       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Assurez-vous d'inclure la clé publique du client dans les serveurs. C:\Users\username\.ssh\authorized_keys fichier.

Enfin, pour aider à faire correspondre l'utilisateur au compte, j'ai trouvé utile d'être plus spécifique avec les données de l'utilisateur sur le client. Au lieu d'utiliser le simple nom d'utilisateur, j'ai utilisé le nom d'utilisateur avec le domaine de l'utilisateur sur le serveur. Dans mon cas, le nom de domaine de mon client C:\Users\UserName\.ssh\config Le fichier ressemblait à ceci :

Host my_short_name
  HostName my.serveraddress.net
  User serversname\username
  IdentityFile .ssh\id_rsa

Dans ce cas, mon serveur Windows 10 s'appellerait nom du serveur (sous le nom du périphérique). En spécifiant l'utilisateur de cette manière, je pourrais éviter l'authentification par mot de passe.

En prime, cela a très bien fonctionné avec un shell par défaut de PowerShell 7. Même mon profil PowerShell par défaut a fonctionné via ssh et j'ai obtenu un support complet pour posh-git et oh-my-posh. Cependant, j'ai trouvé que la méthode par défaut suggérée pour faire de PowerShell l'environnement shell par défaut, (en éditant le fichier ssh_conf pour inclure 'Subsystem powershell c:/progra~1/powershell/7/pwsh.exe -sshs -NoLogo') a fait no travailler pour moi. Au lieu de cela, sur le serveur, utilisez la commande dans une fenêtre PowerShell élevée :

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "c:/progra~1/powershell/7/pwsh.exe" -PropertyType String -Force

Cela crée juste une entrée dans le registre. Vous pouvez toujours aller dans le registre pour la supprimer plus tard si vous le souhaitez.

Answer 3

J'ai minutieusement testé La solution de n0rd sur plusieurs ordinateurs Windows Pro 1809 et 2004. Je suis d'accord avec la plupart de ses étapes.

Configuration du serveur (PowerShell élevé) : Je suis d'accord avec tout.

Configuration du client (PowerShell non élevé) : Je suis d'accord avec tout.

Suite de la configuration du serveur (PowerShell non élevé) : Etapes 1,2,3 : Accepter

Suite de la configuration du serveur (PowerShell non élevé) : Étape 4 : N'effectuez rien à l'étape 4.

Suite de la configuration du serveur (PowerShell non élevé) : Étape 5 : Accepter

Suite de la configuration du serveur (PowerShell non élevé) : Étape 6 : (ajoutée) Décommenter (enlever #) de C:\ProgramData\ssh\sshd_config : #PasswordAuthentication yes

Suite de la configuration du serveur (PowerShell non élevé) : Étape 7 : (ajoutée) Dans Services, redémarrer le serveur SSH OpenSSH.

Je n'ai trouvé aucun problème, avec aucun fichier, concernant la sécurité, les permissions ou l'Unicode. Ils étaient tous corrects dès la sortie de la boîte.

Answer 4

Je me suis retrouvé dans une situation différente.

Tout d'abord, déboguez comme gWay l'a dit, avec un autre terminal Windows se connectant au serveur.

J'ai read_keyfile_line: C:\\Users\\yieatn\\.ssh/authorized_keys line 1 exceeds size limit

recoder les authorized_keys en utf-8

La raison est que j'ai créé authorized_keys avec cat id_rsa >> authorized_keys et powershell en chinois utilise UTF-16 pour créer des fichiers.

Answer 5

Il s'agit d'une utilisation par défaut de Microsoft très centrée sur la langue anglaise. Les lignes de correspondance des groupes vérifient actuellement la chaîne de version en anglais du groupe Administrateurs appelé 'administrators', ce qui échoue sur de nombreuses installations de Windows dans d'autres langues. Sur une installation allemande, cette ligne doit être remplacée par "administratoren". Ils feraient mieux de rendre possible la correspondance des groupes par SID à la place. (Ceci est encore plus important dans la fonction de correspondance DenyGroups - je ne l'ai pas encore testé - mais s'ils vérifient les chaînes de caractères au lieu du SID, alors les refus n'ont aucun sens et sont facilement contournés en utilisant une installation dans une autre langue de Windows).

( voir aussi https://github.com/MicrosoftDocs/windowsserverdocs/issues/1911#issuecomment-771552030 )