Chia sẻ khóa SSH riêng với Bash trên Windows

Tôi đã cài đặt Windows 10 với Git. Git này sử dụng C:/Users/MyNamethư mục của tôi làm thư mục HOME và /.ssh/thư mục bên trong, một cách thích hợp để tìm nguồn cung cấp các khóa SSH riêng tư của tôi.

Tôi vừa kích hoạt và thiết lập "Bash trên Ubuntu trên Windows" (thật là hay!) Và cũng đã cài đặt Git trong đó. Tôi muốn cả hai Gits sử dụng cùng một bộ khóa sao cho không quan trọng tôi làm việc trong môi trường nào trên máy này, các cam kết của tôi sẽ luôn đến từ tôi.

Rắc rối là thư mục HOME trong bash khác ( /home/MyName) và do đó nó không nhìn thấy các phím nằm ở vị trí xa ../../mnt/c/Users/MyName/.ssh. Tôi nghĩ tôi sẽ trở thành người chiến thắng bằng cách thay đổi biến môi trường HOME bằng cách sử dụng

export HOME=/c/mnt/Users/MyName

Điều này đã thay đổi thư mục HOME thành công nhưng bash git vẫn không thấy các khóa có trong ./.sshthư mục.

Tôi không chắc đây có phải là A) không vì bash git mong đợi các khóa ở định dạng tệp khác? (hiện tại là id_rsavà id_rsa.pub) B) bash git đang bỏ qua biến HOME đã thay đổi? Hoặc có thể cả hai.

Tôi cũng không chắc chắn C) nếu thay đổi tùy ý biến HOME như thế này có phải là một ý tưởng tốt trong các chương trình khác có thể tham chiếu nó không?

— Toby
nguồn

Có vẻ như đã đến lúc cho một liên kết tượng trưng.

— Telastyn

Hmm .sshđã tồn tại ở /home/MyName... một tập tin symlink? như vậy tôi sẽ làm gì ln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa? (mới tham gia symlinking!)

— Toby

BÙM! Đó là một điều trị! @Telastyn nếu bạn muốn đưa ra nhận xét của mình thành câu trả lời Tôi sẽ chấp nhận :-) (Mặc dù tôi vẫn không chắc tại sao chỉ thay đổi HOME var không hoạt động ngay từ đầu)

— Toby

Nó hoạt động tốt hơn nếu bạn liên kết toàn bộ .sshthư mục.

— tripleee

Hồi ức của tôi là PuTTY đặt công cụ của mình ở một số vị trí khác nhau nhưng đã hơn một năm kể từ lần cuối tôi phải chạm vào Windows (cảm ơn $ dmr)

— tripleee

Câu trả lời:

Vì vậy, như Telastyn đã nhận xét, tôi đã thêm các liên kết tượng trưng trong WSL ~/.ssh/vào id_rsa và id_rsa.pub bằng cách sử dụng:

> 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

Thay vào đó, sử dụng cùng một kỹ thuật để liên kết thư mục symlink như được đề xuất bởi tripleee, tôi gặp vấn đề cho đến khi tôi thấy rằng các dấu gạch chéo mà tôi đã sử dụng trong lnlệnh (còn lại từ việc sử dụng phím tab để bash điền tên thư mục) là một vấn đề. Vì vậy, thay vì làm như trên, người ta có thể làm tốt hơn:

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

Tệp know_hosts hơi khác nhau giữa việc tôi sử dụng nó (git in powershell bằng ssh-agent) trong Windows và SSH sử dụng nó trong WSL, theo đó tên máy chủ và IP không được băm trong phiên bản Windows. Theo trang man cho ssh-config, có một cờ có sẵn để vô hiệu hóa băm này mà tôi đã hiểu là SSH sẽ hiểu tệp mà không cần băm cho đến nay.

Phương thức sau này có nghĩa là các chi tiết được sử dụng cho SSH được sử dụng giữa hai môi trường khác nhau hoàn toàn giống nhau.

Cảm ơn Matěj Kříž vì đã chỉ ra một nhân vật mất tích nhỏ nhưng quan trọng!

— Toby
nguồn

Nó nên được > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsathêm "~". Không?

— Matěj Kříž

lưu ý rằng không thể sử dụng private keystừ bash on windowsnếu chúng tạo s linkgiữa các thư mục. Làm như vậy sẽ gây ra ssh agentkhiếu nại về sự cho phép xấu trên các tệp khóa riêng. Vì các tập tin được gắn từ cửa sổ, sự cho phép của họ không thể thay đổi.

— gỗ sồi

@oak là có thể với bash?

— Tj Gienger

@TjGienger có ý gì?

— gỗ sồi

@oak, đây có phải là những gì Entity Black đang cố gắng khắc phục dưới đây ? Hay đó là giải quyết một vấn đề khác nhau?

— sferencik

Dựa trên quyền xây dựng mới "Insider Build 17063" cho các tệp hoạt động khác nhau ngay bây giờ. Tóm lại bạn cần làm:

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

Điều này sẽ làm cho quyền cho thư mục ssh của bạn hoạt động như bạn cần. Sau đó, mua sắm như OP gợi ý trong câu trả lời của mình.

Các liên kết có liên quan:

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

BIÊN TẬP

Tôi trở lại câu hỏi này vì tôi phát hiện ra đây chỉ là giải pháp tạm thời (vâng tôi ngu ngốc). Mỗi lần bạn khởi động lại (đăng xuất) WSL của mình, bạn cần truyền lại lệnh này.

Vì vậy, giải pháp phù hợp với tôi bây giờ là chỉnh sửa (tạo) tệp cấu hình /etc/wsl.conftrong wsl ubfox của tôi và đặt bên trong sau, sau đó khởi động lại để thực hiện gắn kết lại:

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

Tại sao tôi thêm siêu dữ liệu:

Quyền Linux được thêm dưới dạng siêu dữ liệu bổ sung vào tệp. Điều này có nghĩa là một tệp có thể có các bit cho phép đọc / ghi / thực thi Linux và Windows.

Tại sao đặt uid và gid:

Theo mặc định, WSL đặt uid và gid thành giá trị của người dùng mặc định (trong bản phân phối Ubuntu, người dùng mặc định được tạo với uid = 1000, gid = 1000). Nếu người dùng chỉ định rõ ràng tùy chọn gid hoặc uid thông qua khóa này, giá trị liên quan sẽ bị ghi đè. Nếu không, giá trị mặc định sẽ luôn được nối thêm.

Các liên kết có liên quan:

https://docs.microsoft.com/en-us/windows/wsl/wsl-config https://bloss.msdn.microsoft.com/commandline/2018/02/07/automatically-configuring-wsl/ https: / /bloss.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/

— Thực thể đen
nguồn