web-dev-qa-db-fra.com

Partager des clés SSH privées avec Bash sous Windows

J'ai Windows 10 avec Git installé. Ce Git utilise mon C:/Users/MyName dir comme répertoire HOME et /.ssh/ dir dedans, de manière appropriée pour trouver mes clés SSH privées.

Je viens d'activer et de configurer "Bash sur Ubuntu sur Windows" (quelle bouchée!) Et d'y installer également Git. J'aimerais que les deux Gits utilisent le même jeu de clés de sorte que peu importe l'environnement dans lequel je travaille sur cette machine, mes commits proviendront toujours de moi.

Le problème étant que le répertoire HOME en bash est différent (/home/MyName) et donc il ne voit pas les clés situées dans le désormais distant ../../mnt/c/Users/MyName/.ssh. Je pensais être sur le point de gagner en changeant la variable d'environnement HOME en utilisant

export HOME=/c/mnt/Users/MyName

Cela a changé le répertoire HOME avec succès mais le git bash ne voit toujours pas les clés contenues dans le ./.ssh dir.

Je ne sais pas si c'est A) parce que bash git attend des clés dans un format de fichier différent? (les actuels sont id_rsa et id_rsa.pub) B) bash git ignore la variable HOME modifiée? Ou peut-être les deux.

Je ne suis pas sûr non plus C) si changer arbitrairement la variable HOME comme ceci est une bonne idée en général avec d'autres programmes qui pourraient la référencer?

gitauthenticationbashubuntuwindows-10
18
Toby

Donc, comme Telastyn l'a commenté, j'ai ajouté des liens symboliques dans les WSL ~/.ssh/ à id_rsa et id_rsa.pub en utilisant:

> ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsa
> ln -s /mnt/c/Users/MyName/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub

En utilisant la même technique pour lier à la place le répertoire du lien symbolique comme suggéré par tripleee, j'ai eu des problèmes jusqu'à ce que je vois que les barres obliques que j'ai utilisées dans la commande ln (à partir de l'utilisation de la touche de tabulation pour que bash remplisse le répertoire nom) étaient un problème. Ainsi, au lieu de faire ce qui précède, on pourrait mieux faire:

> ln -s /mnt/c/Users/Myname/.ssh ~/.ssh

Le fichier known_hosts diffère légèrement entre mon utilisation (git dans powershell à l'aide de l'agent ssh) dans Windows et son utilisation SSH dans WSL, où le nom d'hôte et l'IP ne sont pas hachés dans la version Windows. Selon la page de manuel de ssh-config, un indicateur est disponible pour désactiver ce hachage, ce que j'ai compris comme signifiant que SSH comprendrait le fichier sans le hachage qui a fonctionné jusqu'à présent.

Cette dernière méthode signifie que les détails utilisés pour SSH utilisés entre les deux environnements différents sont exactement les mêmes.

Merci à Matěj Kříž d'avoir signalé un petit personnage manquant mais vital!

19
Toby

Basé sur la nouvelle construction, les autorisations "Insider Build 17063" pour les fichiers fonctionnent différemment maintenant. En bref, vous devez faire:

Sudo umount /mnt/c
Sudo mount -t drvfs C: /mnt/c -o metadata

Cela fera fonctionner les autorisations pour votre dossier ssh selon vos besoins. Ensuite, comme OP le suggère dans sa réponse.

Liens pertinents:

https://github.com/Microsoft/WSL/issues/3181https://blogs.msdn.Microsoft.com/commandline/2018/01/12/chmod-chown- améliorations-wsl /

[~ # ~] modifier [~ # ~]

Je reviens à cette question car je découvre que ce n'est qu'une solution temporaire (oui je suis stupide). À chaque redémarrage (déconnexion) de votre WSL, vous devez à nouveau caster ces commandes.

La solution qui me convient maintenant consiste donc à modifier (créer) le fichier de configuration /etc/wsl.conf dans mon wsl ubuntu, et mis à l'intérieur suivant, puis redémarrez pour refaire les montages:

# Enable extra metadata options by default, set uid and gid to 0
[automount]
options = "metadata,uid=,gid="

Pourquoi j'ajoute des métadonnées:

Les autorisations Linux sont ajoutées en tant que métadonnées supplémentaires au fichier. Cela signifie qu'un fichier peut avoir des bits d'autorisation de lecture/écriture/exécution pour Linux et Windows.

Pourquoi définir uid et gid:

Par défaut, WSL définit l'uid et le gid sur la valeur de l'utilisateur par défaut (dans la distribution Ubuntu, l'utilisateur par défaut est créé avec uid = 1000, gid = 1000). Si l'utilisateur spécifie explicitement une option gid ou uid via cette clé, la valeur associée sera écrasée. Sinon, la valeur par défaut sera toujours ajoutée.

Liens pertinents:

https://docs.Microsoft.com/en-us/windows/wsl/wsl-confighttps://blogs.msdn.Microsoft.com/commandline/2018/02/ 07/automatiquement-configuring-wsl /https://blogs.msdn.Microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/

11
Entity Black