Windows上のBashとプライベートSSHキーを共有する


18

GitがインストールされたWindows 10があります。このGitは、私のC:/Users/MyNameディレクトリをHOMEディレクトリとして使用し、/.ssh/内部のディレクトリを使用して、適切に秘密のSSHキーを取得します。

「Windows上のUbuntuでのBash」を有効にしてセットアップし(口一杯です!)、そこにGitもインストールしました。両方のGitsに同じキーのセットを使用して、このマシンで作業する環境が問題にならないようにしたいと思います。コミットは常に私から行われます。

bashのHOMEディレクトリーが異なる(/home/MyName)ため、現在遠くにあるキーが表示されないという問題があります../../mnt/c/Users/MyName/.ssh。HOME環境変数を次のように変更することで、勝者になると思いました。

export HOME=/c/mnt/Users/MyName

これにより、HOMEディレクトリが正常に変更されましたが、bash gitはまだ./.sshディレクトリ内に含まれるキーを認識しません。

これがA)かどうかはわかりませんが、これはbash gitが異なるファイル形式のキーを想定しているためですか?(現在のものはid_rsaand id_rsa.pub)B)bash gitは変更されたHOME変数を無視していますか?または多分両方。

また、C)このようにHOME変数を任意に変更することが、それを参照する可能性のある他のプログラムについて一般的に良いアイデアであるかどうかもわかりません


2
シンボリックリンクの時間のようですね。
テラスティン

うーんは.sshすでに存在してい/home/MyNameます... 1つのシンボリックリンクファイルができますか?私がするようなことln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa?(シンボリックリンクも新しい!)
トビー

ブーム!それは御works走です!@Telastynあなたが答えにあなたのコメントをしたいのですがあれば、私は受け入れるだろう:-)(ちょうどHOMEのVARを変更することが最初の場所では動作しませんでした、なぜ私はまだわからないんだけど)
トビー

2
.sshディレクトリ全体をシンボリックリンクすると、より適切に動作します。
トリプリー

1
私の記憶では、PuTTYはすべてを別の場所に置いていますが、最後にWindowsに触れなければならなかったので1年以上経ちました($ dmrに感謝)
tripleee

回答:


19

Telastynがコメントしたよう~/.ssh/に、次を使用してid_rsaおよびid_rsa.pub にWSLのシンボリックリンクを追加しました。

> 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

tripleeeによって提案されたシンボリックリンクディレクトリを代わりにリンクするために同じ手法を使用して、lnコマンドで使用した末尾のスラッシュ(bashを使用してディレクトリ名を入力するために残した)が問題であることがわかるまで問題がありました。したがって、上記の方法を実行する代わりに、次のようにすることをお勧めします。

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

known_hostsファイルは、Windowsでの使用(ssh-agentを使用するpowershellでのgit)とWSLでのSSHの使用とで若干異なります。そのため、Windowsバージョンではホスト名とIPはハッシュされません。ssh-configのmanページによると、このハッシュを無効にするために利用できるフラグがあり、これはSSHがこれまでのところうまく機能していないハッシュなしでファイルを理解することを意味します。

この後者の方法は、2つの異なる環境間で使用されるSSHに使用される詳細がまったく同じであることを意味します。

小さくても重要な行方不明のキャラクターを指摘してくれたMatějKřížに感謝します!


3
> ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsa「〜」を追加する必要があります。いや?
マテイKříž

7
ディレクトリ間でprivate keysfrom bash on windowsif を使用することはできないことに注意してくださいs link。これを行うとssh agent、秘密鍵ファイルの不正なアクセス権について文句を言うことになります。ファイルはウィンドウからマウントされるため、アクセス許可を変更することはできません。
オーク

@oakはbashでまったく可能ですか?
Tj Gienger

@TjGiengerどういう意味ですか?
オーク

@oak、これはおそらくエンティティブラックが修正しようとしているものですか?または、別の問題に対処していますか?
sferencik

10

ファイルの新しいビルド「Insider Build 17063」権限に基づいて、現在は異なる動作をします。要するに、あなたがする必要があります:

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

これにより、sshフォルダーのアクセス許可が必要に応じて機能します。その後、OPが彼の答えで示唆しているように進めました。

関連リンク:

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

編集

これは一時的な解決策にすぎないことがわかったためです(はい、私は愚かです)。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/

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.