Teilen Sie private SSH-Schlüssel mit Bash unter Windows

Ich habe Windows 10 mit Git installiert. Dieser Git verwendet mein C:/Users/MyNameVerzeichnis als HOME-Verzeichnis und das Verzeichnis darin /.ssh/, um meine privaten SSH-Schlüssel zu finden.

Ich habe gerade "Bash on Ubuntu on Windows" aktiviert und eingerichtet (was für ein Mund voll!) Und Git darin auch installiert. Ich möchte, dass beide Gits denselben Schlüsselsatz verwenden, sodass es keine Rolle spielt, in welcher Umgebung ich auf diesem Computer arbeite. Meine Commits kommen immer von mir.

Das Problem ist, dass das HOME-Verzeichnis in bash anders ist ( /home/MyName) und daher die Tasten nicht in der Ferne angezeigt werden ../../mnt/c/Users/MyName/.ssh. Ich dachte, ich würde zu einem Gewinner werden, indem ich die Umgebungsvariable HOME mit ändere

export HOME=/c/mnt/Users/MyName

Dies hat das HOME-Verzeichnis erfolgreich geändert, aber der Bash-Git sieht immer noch nicht die in dem Verzeichnis enthaltenen Schlüssel ./.ssh.

Ich bin nicht sicher, ob dies A) ist, weil bash git Schlüssel in einem anderen Dateiformat erwartet? (aktuelle sind id_rsaund id_rsa.pub) B) Bash Git ignoriert die geänderte HOME Variable? Oder vielleicht beides.

Ich bin mir auch nicht sicher, ob C) eine willkürliche Änderung der HOME-Variablen wie diese im Allgemeinen eine gute Idee für andere Programme ist, die darauf verweisen könnten?

— Toby
quelle

Klingt so, als wäre es Zeit für einen Symlink.

— Telastyn

Hmm .sshexistiert schon bei /home/MyName... kann man symlink files? so dass ich tun würde ln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa? (Neu bei Symlinking auch!)

— Toby

BOOM! Das ist ein Genuss! @Telastyn, wenn Sie Ihren Kommentar in eine Antwort umwandeln möchten, nehme ich an :-) (Obwohl ich immer noch nicht sicher bin, warum das Ändern des HOME-Var überhaupt nicht funktioniert hat)

— Toby,

Es funktioniert besser, wenn Sie das gesamte .sshVerzeichnis mit Symlinks verknüpfen .

— Tripleee

Ich erinnere mich, dass PuTTY seine Sachen an einem anderen Ort abgelegt hat, aber es ist über ein Jahr her, seit ich das letzte Mal Windows berühren musste (danke $ dmr)

— Tripleee

Antworten:

Als Telastyn kommentierte, fügte ich Symlinks in WSLs ~/.ssh/zu id_rsa und id_rsa.pub hinzu:

> 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

Unter Verwendung der gleichen Technik, um stattdessen das Symlink-Verzeichnis wie von Tripleee vorgeschlagen zu verknüpfen, hatte ich Probleme, bis ich sah, dass die abschließenden Schrägstriche, die ich in der verwendete ln Befehl verwendete (von der Verwendung der Tabulatortaste zum Ausfüllen des Verzeichnisnamens durch Bash), ein Problem waren. Anstatt das oben genannte zu tun, könnte man also besser tun:

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

Die Datei known_hosts unterscheidet sich geringfügig zwischen meiner Verwendung (Git in Powershell mit dem SSH-Agenten) in Windows und der SSH-Verwendung in WSL, wobei Hostname und IP in der Windows-Version nicht gehasht werden. Laut der Manpage für ssh-config gibt es ein Flag zum Deaktivieren dieses Hashings, was bedeutet, dass SSH die Datei ohne das bisherige Hashing verstehen würde.

Diese letztere Methode bedeutet, dass die für SSH verwendeten Details zwischen den beiden verschiedenen Umgebungen genau gleich sind.

Vielen Dank an Matěj Kříž für den Hinweis auf eine kleine, aber wichtige fehlende Figur!

— Toby
quelle

Es sollte > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsa"~" hinzugefügt werden. Nee?

— Matěj Kříž

Beachten Sie, dass es nicht möglich ist, zwischen den Verzeichnissen private keysfrom bash on windowsif ones zu verwenden s link. Andernfalls wird eine ssh agentschlechte Berechtigung für private Schlüsseldateien beanstandet. Da die Dateien aus dem Fenster gemountet wurden, können ihre Berechtigungen nicht geändert werden.

— Eiche

@oak geht das überhaupt mit bash?

— Tj Gienger

@TjGienger was meinst du?

— Eiche

@oak, ist das vielleicht das, was die Entity Black unten zu beheben versucht ? Oder ist das ein anderes Thema?

— sferencik

Basierend auf dem neuen Build "Insider Build 17063" funktionieren die Berechtigungen für Dateien jetzt anders. Kurz gesagt, müssen Sie Folgendes tun:

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

Dadurch funktionieren die Berechtigungen für Ihren SSH-Ordner nach Bedarf. Dann verarbeitet wie OP in seiner Antwort vorschlägt.

Relevante Links:

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

BEARBEITEN

Ich komme auf diese Frage zurück, weil ich herausfinde, dass dies nur eine vorübergehende Lösung ist (ja, ich bin dumm). Bei jedem Neustart (Abmelden) Ihrer WSL müssen Sie diese Befehle erneut ausführen.

Die Lösung, die jetzt für mich funktioniert, besteht darin, die Konfigurationsdatei /etc/wsl.confin meinem wsl-Ubuntu zu bearbeiten (zu erstellen) und die folgenden Schritte auszuführen und dann neu zu starten, um die Mounts erneut auszuführen:

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

Warum ich Metadaten hinzufüge:

Linux-Berechtigungen werden der Datei als zusätzliche Metadaten hinzugefügt. Dies bedeutet, dass eine Datei über Lese- / Schreib- / Ausführungsberechtigungsbits für Linux und Windows verfügen kann.

Warum setzen Sie uid und gid:

Standardmäßig setzt WSL die UID und GID auf den Wert des Standardbenutzers (in Ubuntu Distribution wird der Standardbenutzer mit UID = 1000, GID = 1000 erstellt). Wenn der Benutzer eine GID- oder UID-Option explizit über diesen Schlüssel angibt, wird der zugehörige Wert überschrieben. Andernfalls wird immer der Standardwert angehängt.

Relevante Links:

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/

— Entität Schwarz
quelle