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

J'ai Windows 10 avec Git installé. Ce Git utilise mon C:/Users/MyNamerépertoire comme répertoire HOME et le répertoire qu'il /.ssh/contient, 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 ./.sshrépertoire.

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 le sont id_rsaet 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 par rapport à d'autres programmes qui pourraient la référencer?

— Toby
source

On dirait qu'il est temps pour un lien symbolique.

— Telastyn

Hmm .sshexiste déjà sur /home/MyName... peut-on créer des liens symboliques? telle que je ferais ln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa? (nouveau sur les liens symboliques aussi!)

— Toby

BOOM! Ça marche un régal! @Telastyn si vous souhaitez faire de votre commentaire une réponse, j'accepterai :-) (bien que je ne sache toujours pas pourquoi le simple fait de changer la var HOME n'a pas fonctionné en premier lieu)

— Toby

Cela fonctionne mieux si vous créez un lien symbolique vers le .sshrépertoire entier .

— tripleee

Si je me souviens bien, PuTTY met ses trucs dans un tout autre endroit, mais cela fait plus d'un an que j'ai dû toucher Windows pour la dernière fois (merci $ dmr)

— tripleee

Réponses:

Donc, comme Telastyn l'a commenté, j'ai ajouté des liens symboliques dans les WSL ~/.ssh/vers 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 voie que les barres obliques que j'ai utilisées dans la lncommande (à partir de l'utilisation de la touche de tabulation pour que bash remplisse le nom du répertoire) é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!

— Toby
source

Il faut > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsaajouter "~". Nan?

— Matěj Kříž

notez qu'il n'est pas possible d'utiliser le private keysfrom bash on windowsif fait s linkentre les répertoires. Sinon, vous ssh agentvous plaindrez d'une mauvaise autorisation sur les fichiers de clés privées. Étant donné que les fichiers montés à partir de la fenêtre, leur autorisation ne peut pas être modifiée.

— chêne

@oak est-ce possible avec bash?

— Tj Gienger

@TjGienger que voulez-vous dire?

— chêne

@oak, est-ce peut-être ce que l'Entity Black essaie de résoudre ci - dessous ? Ou s'agit-il d'un problème différent?

— sferencik

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/3181 https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/

ÉDITER

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.

Donc la solution qui fonctionne pour moi maintenant est d'éditer (créer) un fichier de configuration /etc/wsl.confdans mon wsl ubuntu, et de le mettre à l'intérieur, puis de redémarrer 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-config https://blogs.msdn.microsoft.com/commandline/2018/02/07/automatically-configuring-wsl/ https: / /blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/

— Entity Black
source