Compartilhe chaves SSH privadas com o Bash no Windows

Eu tenho o Windows 10 com o Git instalado. Este Git usa meu C:/Users/MyNamediretório como diretório HOME e o /.ssh/diretório interno, apropriadamente para obter minhas chaves SSH privadas.

Acabei de ativar e configurar o "Bash no Ubuntu no Windows" (que bocado!) E instalei o Git também. Gostaria que os dois Gits usassem o mesmo conjunto de chaves, para que não importasse em que ambiente eu trabalhasse nesta máquina, meus commits sempre virão de mim.

O problema é que o diretório HOME no bash é diferente ( /home/MyName) e, portanto, ele não vê as chaves localizadas no agora distante ../../mnt/c/Users/MyName/.ssh. Eu pensei que seria um vencedor mudando a variável de ambiente HOME usando

export HOME=/c/mnt/Users/MyName

Isso mudou o diretório HOME com êxito, mas o bash git ainda não vê as chaves contidas no ./.sshdiretório.

Não tenho certeza se isso é A) porque o bash git espera chaves em um formato de arquivo diferente? (os atuais são id_rsae id_rsa.pub) B) o bash git está ignorando a variável HOME alterada? Ou talvez ambos.

Também não tenho certeza C) se alterar arbitrariamente a variável HOME como essa é uma boa idéia, em geral, em outros programas que possam fazer referência a ela?

— Toby
fonte

Parece que é hora de um link simbólico.

— Telastyn

Hmm .sshjá existe em /home/MyName... pode-se ligar um arquivo? tal que eu faria ln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa? (novo para criar um link simbólico também!)

— Toby

ESTRONDO! Isso funciona um prazer! @Telastyn se você gostaria de fazer o seu comentário em uma resposta eu vou aceitar :-) (Embora eu ainda não tenho certeza por que apenas mudando HOME var não funcionou em primeiro lugar)

— Toby

Funciona melhor se você vincular o .sshdiretório inteiro .

— Tripleee 11/11

Minha lembrança é que PuTTY coloca seu material em completamente algum local diferente, mas tem sido mais de um ano desde a última vez tinha que tocar o Windows (obrigado $ DMR)

— tripleee

Respostas:

Então, como Telastyn comentou, adicionei links simbólicos nas WSLs ~/.ssh/ao 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 a mesma técnica para vincular o diretório de link simbólico, conforme sugerido pelo triplo, eu tive problemas até perceber que as barras finais que eu usei no lncomando (deixadas de usar a tecla tab para ter o bash preenchendo o nome do diretório) eram um problema. Assim, em vez de fazer o acima, seria melhor:

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

O arquivo known_hosts difere um pouco entre o meu uso dele (git no powershell usando o ssh-agent) no Windows e o uso SSH dele na WSL, em que o nome do host e o IP não são divididos na versão do Windows. De acordo com a página de manual do ssh-config, há um sinalizador disponível para desativar esse hash, o que eu entendi como o SSH entenderia o arquivo sem o hash que funcionou até agora.

Esse último método significa que os detalhes usados para SSH usados entre os dois ambientes diferentes são exatamente os mesmos.

Obrigado a Matěj Kříž por apontar um personagem desaparecido pequeno, mas vital!

— Toby
fonte

Deve ser > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsaadicionado "~". Não?

— Matěj Kříž

note que não é possível usar o private keysfrom bash on windowsif ones s linkentre os diretórios. Fazer isso fará com ssh agentque reclamar de permissão incorreta em arquivos de chave privada. Como os arquivos montados a partir da janela, sua permissão não pode ser alterada.

— carvalho

@ oak é possível com bash?

— Tj Gienger

@TjGienger, o que você quer dizer?

— carvalho

@ Oak, isso é talvez o que o Entity Black está tentando corrigir abaixo ? Ou isso está resolvendo um problema diferente?

— Sferencik

Com base na nova compilação, as permissões "Insider Build 17063" para arquivos funcionam de maneira diferente agora. Em suma, você precisa fazer:

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

Isso fará com que as permissões para sua pasta ssh funcionem conforme necessário. Então proceda como OP sugere em sua resposta.

Links relevantes:

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

EDITAR

Estou de volta a esta pergunta porque descobri que essa é apenas uma solução temporária (sim, sou burra). Cada vez que você reinicia (efetua logout) sua WSL, é necessário converter esses comandos novamente.

Portanto, a solução que funciona para mim agora é editar (criar) o arquivo de configuração /etc/wsl.confno meu wsl ubuntu e colocar dentro do seguinte, depois reiniciar para fazer montagens novamente:

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

Por que adiciono metadados:

Permissões do Linux são adicionadas como metadados adicionais ao arquivo. Isso significa que um arquivo pode ter Linux e Windows para ler / gravar / executar bits de permissão.

Por que definir uid e gid:

Por padrão, o WSL define o uid e o gid para o valor do usuário padrão (na distribuição do Ubuntu, o usuário padrão é criado com uid = 1000, gid = 1000). Se o usuário especificar uma opção gid ou uid explicitamente por meio dessa chave, o valor associado será substituído. Caso contrário, o valor padrão será sempre acrescentado.

Links 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/

— Entidade preta
fonte