Executando o Fedora no WSL2, descobri que a ativação do socket ssh-agent
não funciona corretamente: a primeira solicitação que aciona o início real do serviço falha. Pode ser uma solicitação git fetch
or git pull
ou então uma ssh-add
chamada. Isso aparece como um longo tempo limite na chamada do cliente em vez de uma falha imediata.
Como a configuração do systemd contém ambos ssh-agent.socket
e ssh-agent.service
, tentar desabilitar ssh-agent.socket
e habilitar ssh-agent.service
diretamente não funciona, pois apenas reativa a ativação do soquete em vez de configurar o serviço para iniciar automaticamente:
~$ systemctl --user is-enabled ssh-agent.socket
enabled
~$ systemctl --user is-enabled ssh-agent.service
indirect
~$ systemctl --user enable ssh-agent.service
~$ systemctl --user is-enabled ssh-agent.service
indirect
~$ systemctl --user disable ssh-agent.socket
Removed "/home/acoghlan/.config/systemd/user/sockets.target.wants/ssh-agent.socket".
~$ systemctl --user enable ssh-agent.service
Created symlink /home/acoghlan/.config/systemd/user/sockets.target.wants/ssh-agent.socket → /usr/lib/systemd/user/ssh-agent.socket.
O OpenSSH ssh-agent não suporta ativação de soquete – ele não sabe que precisa receber transferência de soquete do pai e sempre estabelece seu próprio soquete.
Então, sua primeira solicitação fica presa no limbo dentro da fila do soquete estabelecido pelo systemd (que o ssh-agent acabou de desvincular e substituir pelo seu próprio), enquanto a segunda solicitação agora passa por um soquete diferente que por acaso tem o mesmo nome.
Não é um problema de tempo; a ativação do soquete é "instantânea" por natureza (quando usada com programas que sabem como aceitá-la), especificamente porque a solicitação inicial permanece na fila de soquetes pelo tempo que o programa precisa inicializar antes de pegá-la – o que é, na verdade, o que leva a esse problema quando o programa não sabe como aceitá-la. (Então é meio que o oposto de "precisar de tempo para se resolver".)
Em vez de ajustar a configuração do systemd (que não só provavelmente acabará sendo específica da distribuição e pode mudar com o tempo, mas também afetaria casos em que eu não estava iniciando um shell interativo), eu queria algo que pudesse adicionar ao meu
.bash_profile
que garantisse que ossh-agent
serviço real estivesse sempre em execução para sessões interativas, não apenas um soquete de escuta.ssh-add -l
(listando impressões digitais de chaves carregadas) parecia um bom comando de gatilho (já que me lembraria de executarssh-add
se eu estivesse planejando usar SSH),timeout
usado para detectar falhas (já quessh-add -l
normalmente deve ser quase instantâneo se o agente estiver funcionando corretamente).Isso fornece a seguinte solução alternativa (adicionei isso ao final do
.bash_profile
meu diretório inicial):(
ssh-add -l
relata um código de saída de 1 se nenhuma chave for carregada, mas 2 se a tentativa de conexão falhar. Como ostimeout
códigos de falha são todos 124 ou maiores, a verificação[ $? -gt 1 ]
detecta qualquer falha ao tentar ativar o soquete. A verificação apenas dostimeout
códigos de erro frequentemente ainda falha imediatamente após a reinicialização de uma instância com a mensagem "Erro ao conectar ao agente: arquivo ou diretório inexistente")Exemplo de saída de uma nova sessão de terminal após uma reinicialização de instância WSL2: