Özel SSH anahtarlarını Windows'ta Bash ile paylaşın

Git yüklü Windows 10 kullanıyorum. Bu Git, özel SSH anahtarlarımı kaynaklandırmak için uygun şekilde C:/Users/MyNamedizinimi HOME dizini ve içindeki /.ssh/dizini kullanır .

Ben sadece etkinleştirdim ve "Bash Ubuntu on Windows" (ne bir ağız dolusu!) Kurulum ve Git de orada yüklü. Her iki Gits'in de aynı anahtar setini kullanmasını istiyorum, böylece bu makinede hangi ortamda çalıştığım önemli değil, taahhütlerim her zaman benden gelecek.

Bash HOME dir farklı ( /home/MyName) ve bu nedenle şimdi uzak bulunan tuşları görmüyor sorun ../../mnt/c/Users/MyName/.ssh. HOME ortam değişkenini kullanarak kazanan kazanacağımı düşündüm

export HOME=/c/mnt/Users/MyName

Bu HOME dizinini başarılı bir şekilde değiştirdi, ancak bash git hala ./.sshdir içinde bulunan tuşları görmüyor .

Bunun A) olup olmadığından emin değilim çünkü bash git tuşları farklı bir dosya biçiminde bekliyor? (şu anki olanlar id_rsave id_rsa.pub) B) bash git değiştirilmiş HOME değişkenini yok sayıyor mu? Ya da belki ikisi de.

Ayrıca emin değilim C) böyle bir HOME değişkenini keyfi olarak değiştirerek genel wrt buna referans olabilecek diğer programlar iyi bir fikir mi?

— Toby
kaynak

Bir symlink zamanı gelmiş gibi görünüyor.

— Telastyn

Hmm .sshzaten var /home/MyName... bir symlink dosyaları olabilir? öyle yaparım ln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa? (Symlinking'de yeni!)

— Toby

BOOM! Bu bir tedavi işe yarıyor! @Telastyn Eğer cevabınıza yorum yapmak isterseniz, kabul edeceğim :-) (Yine de sadece HOME değişkenini değiştirmenin neden ilk başta işe yaramadığından emin olmasam da)

— Toby

Tüm .sshdizini işaretlerseniz daha iyi çalışır .

— üçlü

Hatırladığım kadarıyla PuTTY eşyalarını tamamen farklı bir yere koyuyor ancak son Windows'a (teşekkür ederim $ dmr) dokunmak zorunda kaldığım bir yıldan uzun bir süre geçti

— üçlü

Yanıtlar:

Telastyn yorumladı gibi ben ~/.ssh/id_rsa ve id_rsa.pub WSLs içinde semboller kullanarak ekledi :

> 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

Bunun yerine üçlünün önerdiği gibi symlink dizinini bağlamak için aynı tekniği kullanarak, lnkomutta kullandığım sondaki eğik çizgiler (bash dizin adını doldurmak için tab tuşunu kullanmaktan ayrıldı) bir sorun olduğunu görünceye kadar sorunları vardı . Böylece, yukarıdakileri yapmak yerine daha iyisini yapabiliriz:

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

Bilinen_hosts dosyası, Windows'ta kullanmam (ssh-agent kullanarak powershell'de git) ve WSL'de SSH kullanımı arasında biraz farklıdır, burada ana bilgisayar adı ve IP, Windows sürümünde karma değildir. Ssh-config için man sayfasına göre, SSH'nin şimdiye kadar çalışmış olan karma olmadan dosyayı anlayacağı anlamına gelen bu karma işlemini devre dışı bırakmak için bir bayrak var.

Bu ikinci yöntem, iki farklı ortam arasında kullanılan SSH için kullanılan ayrıntıların tamamen aynı olduğu anlamına gelir.

Matěj Kříž'e küçük ama hayati bir eksik karakteri işaret ettiği için teşekkürler!

— Toby
kaynak

O olmalı > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsa"~" eklenti. Hayır?

— Matěj Kříž

dizinler arasında olanlar yaparsa private keysfrom kullanılamaz unutmayın . Bunu yapmak , özel anahtar dosyalarındaki kötü izinlerden şikayetçi olur . Pencereden bağlanan dosyalar izinleri değiştirilemez. bash on windowss linkssh agent

— meşe

@ meşe bash ile mümkün mü?

— Tj Gienger

@TjGienger ne demek istiyorsun?

— meşe

@oak, Entity Black'in aşağıda düzeltmeye çalıştığı şey bu mu? Yoksa bu farklı bir sorunu mı ele alıyor?

— sferencik

Yeni "Insider Build 17063" derleme izinlerine göre dosyalar şimdi farklı çalışıyor. Kısacası yapmanız gerekenler:

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

Bu, ssh klasörünüzün izinleri gerektiği gibi çalışmasını sağlar. Daha sonra OP'nin cevabında önerdiği gibi ilerledi.

İlgili bağlantılar:

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

DÜZENLE

Bu soruya geri döndüm çünkü bunun sadece geçici bir çözüm olduğunu anladım (evet aptalım). WSL'nizi her yeniden başlattığınızda (oturumu kapat), bu komutları yeniden yayınlamanız gerekir.

Şimdi benim için çalışan çözüm /etc/wsl.confbenim wsl ubuntu yapılandırma dosyasını düzenlemek (oluşturmak) ve aşağıdaki içine koymak, daha sonra tekrar bağlar yapmak için yeniden başlatmaktır:

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

Neden meta veri ekliyorum:

Linux izinleri, dosyaya ek meta veri olarak eklenir. Bu, bir dosyanın Linux ve Windows'da okuma / yazma / yürütme izin bitlerine sahip olabileceği anlamına gelir.

Neden uid ve gid ayarlandı:

Varsayılan olarak WSL, uid ve gid öğelerini varsayılan kullanıcının değerine ayarlar (Ubuntu dağıtımında, varsayılan kullanıcı uid = 1000, gid = 1000 ile oluşturulur). Kullanıcı bu anahtar aracılığıyla açıkça bir gid veya uid seçeneği belirtirse, ilişkili değerin üzerine yazılır. Aksi takdirde, varsayılan değer her zaman eklenir.

İlgili bağlantılar:

https://docs.microsoft.com/tr-tr/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/

— Varlık Siyahı
kaynak