Condividi le chiavi SSH private con Bash su Windows

Ho installato Windows 10 con Git. Questo Git usa il mio C:/Users/MyNamedir come directory HOME e il /.ssh/dir all'interno, in modo appropriato per l'approvvigionamento delle mie chiavi SSH private.

Ho appena abilitato e configurato "Bash su Ubuntu su Windows" (che bocca piena!) E ho installato anche Git. Vorrei che entrambi Gits usassero lo stesso set di chiavi in modo tale che non importa l'ambiente in cui lavoro su questa macchina, i miei commit verranno sempre da me.

Il problema è che la directory HOME in bash è diversa ( /home/MyName) e quindi non vede le chiavi situate nell'ormai distante ../../mnt/c/Users/MyName/.ssh. Ho pensato di essere vincente cambiando la variabile d'ambiente HOME usando

export HOME=/c/mnt/Users/MyName

Questo ha cambiato la directory HOME con successo ma bash git non vede ancora le chiavi contenute nella ./.sshdirectory.

Non sono sicuro che si tratti di A) perché bash git si aspetta chiavi in un formato di file diverso? (quelli attuali sono id_rsae id_rsa.pub) B) bash git sta ignorando la variabile HOME modificata? O forse entrambi.

Inoltre non sono sicuro C) se cambiare arbitrariamente la variabile HOME in questo modo è una buona idea in generale con altri programmi che potrebbero fare riferimento a essa?

— Toby
fonte

Sembra che sia tempo di un collegamento simbolico.

— Telastyn,

Hmm .sshesiste già su /home/MyName... è possibile un file symlink? tale che vorrei fare ln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa? (nuovo anche per il collegamento simbolico!)

— Toby,

BOOM! Funziona a meraviglia! @Telastyn se vuoi inserire il tuo commento in una risposta, accetterò :-) (Anche se non sono ancora sicuro del perché cambiare la HOME var non abbia funzionato in primo luogo)

— Toby,

Funziona meglio se si collega simbolicamente l'intera .sshdirectory.

— Tripleee

Il mio ricordo è che PuTTY mette le sue cose in una posizione completamente diversa, ma è passato più di un anno dall'ultima volta che ho dovuto toccare Windows (grazie a $ dmr)

— tripleee

Risposte:

Quindi, come ha commentato Telastyn, ho aggiunto collegamenti simbolici in WSL ~/.ssh/a id_rsa e id_rsa.pub usando:

> 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

Usando la stessa tecnica per collegare invece la directory symlink come suggerito da tripleee, ho avuto problemi fino a quando non ho visto che le barre finali che avevo usato nel lncomando (lasciato dall'uso del tasto tab per far compilare bash il nome della directory) erano un problema. Pertanto, invece di fare quanto sopra, è meglio fare:

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

Il file known_hosts differisce leggermente tra il mio utilizzo (git in powershell utilizzando ssh-agent) in Windows e l'uso SSH in WSL, per cui il nome host e l'IP non sono sottoposti a hash nella versione Windows. Secondo la pagina man di ssh-config, è disponibile un flag per disabilitare questo hashing che ho preso per significare che SSH avrebbe capito il file senza l'hash che finora ha funzionato.

Quest'ultimo metodo significa che i dettagli utilizzati per SSH utilizzati tra i due diversi ambienti sono esattamente gli stessi.

Grazie a Matěj Kříž per aver segnalato un personaggio mancante piccolo ma vitale!

— Toby
fonte

Dovrebbe essere > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsaaggiunto "~". No?

— Matěj Kříž,

si noti che non è possibile usare il private keysfrom bash on windowsse si crea s linktra le directory. In questo modo si ssh agentlamenterà una cattiva autorizzazione per i file delle chiavi private. Poiché i file montati dalla finestra non è possibile modificarne l'autorizzazione.

— Quercia

@oak è possibile con bash?

— Tj Gienger,

@TjGienger cosa intendi?

— quercia

@oak, è forse questo ciò che Entity Black sta cercando di risolvere di seguito ? O sta affrontando un problema diverso?

— sferencik,

Basato sulle nuove autorizzazioni "Insider Build 17063" per i file ora funziona diversamente. In breve, devi fare:

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

Ciò farà funzionare le autorizzazioni per la cartella ssh di cui hai bisogno. Quindi proposto come OP suggerisce nella sua risposta.

Link rilevanti:

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

MODIFICARE

Sono tornato a questa domanda perché ho scoperto che questa è solo una soluzione temporanea (sì, sono stupida). Ogni volta che riavvii (disconnetti) il tuo WSL, devi lanciare nuovamente questi comandi.

Quindi la soluzione che funziona per me ora è quella di modificare (creare) il file di configurazione /etc/wsl.confnel mio wsl ubuntu, e mettere dentro il seguente, quindi riavviare per fare di nuovo i montaggi:

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

Perché aggiungo metadati:

Le autorizzazioni di Linux vengono aggiunte come metadati aggiuntivi al file. Ciò significa che un file può avere bit di autorizzazione di lettura / scrittura / esecuzione per Linux e Windows.

Perché impostare uid e gid:

Per impostazione predefinita, WSL imposta uid e gid sul valore dell'utente predefinito (nella distribuzione Ubuntu, l'utente predefinito viene creato con uid = 1000, gid = 1000). Se l'utente specifica esplicitamente un'opzione gid o uid tramite questa chiave, il valore associato verrà sovrascritto. Altrimenti, il valore predefinito verrà sempre aggiunto.

Link rilevanti:

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/

— Entity Black
fonte