Діліться приватними ключами SSH з Bash у Windows

У мене встановлена ​​Windows 10 з Git. Цей Git використовує мій C:/Users/MyNamedir як каталог HOME та /.ssh/dir всередині, відповідним чином для отримання моїх приватних SSH ключів.

Я щойно ввімкнув і встановив "Bash на Ubuntu для Windows" (що за рот!) І також встановив Git у ньому. Я хотів би, щоб обидва Gits використовували один і той же набір клавіш, так що не важливо, в якому середовищі я працюю на цій машині, мої зобов'язання завжди приймуться від мене.

Проблема в тому, що HOME dir в баші відрізняється ( /home/MyName), і, отже, він не бачить клавіш, розташованих у теперішній далекій ../../mnt/c/Users/MyName/.ssh. Я думав, що став би переможцем, змінивши змінну середовища HOME за допомогою

export HOME=/c/mnt/Users/MyName

Це змінило дім HOME успішно, але bash git все ще не бачить клавіш, які містяться в ./.sshdir.

Я не впевнений, чи це A), тому що bash git очікує клавіш у іншому форматі файлу? (Актуальні з них id_rsaі id_rsa.pub) Б) Баш мерзотник ігнорує змінену змінну HOME? А може, і те й інше.

Я також не впевнений, що C) якщо довільна зміна змінної HOME, як це, є хорошою ідеєю в цілому wrt інших програм, які можуть посилатися на неї?

Так, як прокоментував Теластин, я додав посилання на WSL ~/.ssh/до id_rsa та id_rsa.pub, використовуючи:

> 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

Використовуючи ту саму техніку, щоб замість цього посилання на каталог symlink, як це запропонував tripleee, у мене виникли проблеми, поки я не побачив, що кінцеві косої риски, які я використовував у lnкоманді (зліва від використання клавіші вкладки, щоб баш заповнити ім'я каталогу), були проблемою. Таким чином, замість того, щоб сказати вище, можна було б краще зробити:

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

Файл unknown_hosts дещо відрізняється між моїм використанням його (git в powershell за допомогою ssh-агента) у Windows та SSH використанням його у WSL, завдяки чому ім'я хоста та IP не хешируються у версії Windows. Згідно з довідковою сторінкою для ssh-config, доступний прапор для відключення цього хешування, який я вважав, що SSH зрозуміє файл без хешування, який працював до цих пір.

Цей останній метод означає, що деталі, що використовуються для SSH, що використовується між двома різними середовищами, абсолютно однакові.

Дякую Матей Кріж за те, що він вказав на маленького, але життєво важливого зниклого персонажа!

На основі нової збірки "Insider Build 17063" дозволи для файлів зараз працюють інакше. Коротше вам потрібно зробити:

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

Це зробить дозволи для роботи вашої папки ssh так, як вам потрібно. Потім проголошений, як пропонує у своїй відповіді ОП.

Відповідні посилання:

https://github.com/Microsoft/WSL/isissue/3181 https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/

EDIT

Я повертаюся до цього питання, тому що знаходжу це лише тимчасове рішення (так, я дурний). Кожен раз, коли ви перезапускаєте (виходите) з WSL, вам потрібно передати ці команди ще раз.

Тому рішення, яке зараз працює для мене, полягає в тому, щоб відредагувати (створити) конфігураційний файл /etc/wsl.confу моєму wsl ubuntu та ввести всередині наступне, а потім перезапустити, щоб зробити змонтування знову:

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

Чому я додаю метадані:

Дозволи на Linux додаються у файл як додаткові метадані. Це означає, що файл може мати Linux та Windows для читання / запису / виконання дозволів.

Навіщо встановлювати uid та gid:

За замовчуванням WSL встановлює uid та gid значення користувача за замовчуванням (у дистрибутиві Ubuntu користувач за замовчуванням створюється з uid = 1000, gid = 1000). Якщо користувач чітко вказав параметр gid або uid за допомогою цієї клавіші, пов'язане значення буде перезаписано. В іншому випадку значення за замовчуванням завжди буде додано.

Відповідні посилання:

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/