Comparta claves SSH privadas con Bash en Windows

Tengo Windows 10 con Git instalado. Este Git usa mi C:/Users/MyNamedirectorio como el directorio INICIO y el /.ssh/directorio interno, de manera apropiada para obtener mis claves SSH privadas.

Acabo de habilitar y configurar "Bash en Ubuntu en Windows" (¡qué bocado!) E instalé Git allí también. Me gustaría que ambos Gits utilicen el mismo conjunto de claves de modo que no importa en qué entorno trabajo en esta máquina, mis confirmaciones siempre vendrán de mí.

El problema es que el directorio HOME en bash es diferente ( /home/MyName) y, por lo tanto, no ve las teclas ubicadas en el ahora distante ../../mnt/c/Users/MyName/.ssh. Pensé que sería un ganador cambiando la variable de entorno HOME usando

export HOME=/c/mnt/Users/MyName

Esto cambió el directorio HOME con éxito, pero bash git todavía no ve las claves contenidas en el ./.sshdirectorio.

No estoy seguro de si esto es A) porque bash git espera claves en un formato de archivo diferente. (las actuales son id_rsay id_rsa.pub) B) bash git está ignorando la variable HOME modificada? O tal vez ambos.

Tampoco estoy seguro de C) si cambiar arbitrariamente la variable HOME como esta es una buena idea en general, ¿otros programas que podrían hacer referencia a ella?

— Toby
fuente

Parece que es hora de un enlace simbólico.

— Telastyn

Hmm .sshya existe en /home/MyName... ¿pueden uno archivos de enlace simbólico? tal que haría ln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa? (¡nuevo en simular también!)

— Toby

¡AUGE! Eso funciona de maravilla! @Telastyn si desea que su comentario se convierta en una respuesta, aceptaré :-) (Aunque todavía no estoy seguro de por qué solo cambiar la variable HOME no funcionó en primer lugar)

— Toby

Funciona mejor si hace un enlace simbólico a todo el .sshdirectorio.

— tripleee

Recuerdo que PuTTY pone sus cosas en una ubicación completamente diferente, pero ha pasado más de un año desde la última vez que tuve que tocar Windows (gracias $ dmr)

— tripleee

Respuestas:

Entonces, como comentó Telastyn, agregué enlaces simbólicos en 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 misma técnica para vincular en su lugar el directorio de enlaces simbólicos sugerido por tripleee, tuve problemas hasta que vi que las barras diagonales finales que utilicé en el lncomando (dejado de usar la tecla de tabulación para que bash complete el nombre del directorio) fueron un problema. Por lo tanto, en lugar de hacer lo anterior, podría hacer mejor:

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

El archivo conocido_hosts difiere ligeramente entre mi uso de él (git en powershell usando el agente ssh) en Windows y el uso de SSH en WSL, por lo que el nombre de host y la IP no están codificados en la versión de Windows. De acuerdo con la página del manual para ssh-config, hay un indicador disponible para deshabilitar este hash, lo que entendí que SSH entendería el archivo sin el hashing que ha funcionado hasta ahora.

Este último método significa que los detalles utilizados para SSH utilizados entre los dos entornos diferentes son exactamente los mismos.

¡Gracias a Matěj Kříž por señalar un pequeño pero vital personaje perdido!

— Toby
fuente

Se debe > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsaagregar "~". No?

— Matěj Kříž

tenga en cuenta que no es posible usar private keysfrom bash on windowsif ones hace s linkentre los directorios. Si lo hace, se ssh agentquejará de los malos permisos en los archivos de clave privada. Dado que los archivos montados desde la ventana, su permiso no se puede cambiar.

— roble

@oak, ¿es posible con bash?

— Tj Gienger

@TjGienger, ¿qué quieres decir?

— roble

@oak, ¿es esto quizás lo que la Entidad Negra está tratando de arreglar a continuación ? ¿O es eso abordar un problema diferente?

— sferencik

Según los permisos de la nueva compilación "Insider Build 17063" para archivos, ahora funciona de manera diferente. En resumen, debes hacer:

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

Esto hará que los permisos para su carpeta ssh funcionen según lo necesite. Luego procedió como OP sugiere en su respuesta.

Enlaces relevantes:

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

EDITAR

Volví a esta pregunta porque descubrí que esto es solo una solución temporal (sí, soy estúpido). Cada vez que reinicie (cierre la sesión) de su WSL, debe emitir estos comandos nuevamente.

Entonces, la solución que me funciona ahora es editar (crear) el archivo de configuración /etc/wsl.confen mi wsl ubuntu, y ponerlo en el siguiente, luego reiniciar para hacer monturas nuevamente:

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

Por qué agrego metadatos:

Los permisos de Linux se agregan como metadatos adicionales al archivo. Esto significa que un archivo puede tener bits de permiso de lectura / escritura / ejecución de Linux y Windows.

¿Por qué configurar uid y gid?

De manera predeterminada, WSL establece el uid y el gid en el valor del usuario predeterminado (en la distribución de Ubuntu, el usuario predeterminado se crea con uid = 1000, gid = 1000). Si el usuario especifica una opción gid o uid explícitamente a través de esta clave, se sobrescribirá el valor asociado. De lo contrario, siempre se agregará el valor predeterminado.

Enlaces relevantes:

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/

— Entidad negro
fuente