ssh-agent não adicionando chave quando iniciado graficamente

Question

Recentemente adicionei o seguinte script ao meu início automático (no KDE):

eval 'ssh-agent'
ssh-add

O script deve ser iniciado no login e pedir minha senha e carregar minha chave secreta. Faz quase bem. Os scripts são executados corretamente e o agente é iniciado, e as variáveis de ambiente estão todas configuradas, e me pedem minha senha. O único problema é que a chave não é carregada depois disso. Mas se eu entro em ssh-add em um terminal, sou perguntado pela minha senha e a chave é armazenada para o resto da minha sessão X.

O que estou fazendo de errado? Por que a chave não está carregada, mesmo que eu seja perguntada pela minha frase secreta?

PS: Eu estou rodando no Debian jessie.

    

Answer 1

Existem dois cenários possíveis que podem estar causando isso.

Ambos resultam do fato de que muitos gerentes de desktop lançam seu próprio agente de chave ssh. Isso é feito porque o agente precisa ser iniciado antes do gerenciador da área de trabalho para que as variáveis exportadas sejam selecionadas pelos aplicativos iniciados pelo gerenciador da área de trabalho (seu emulador de terminal).

1. O seu gerenciador de desktop está lançando seu próprio agente ssh depois que você inicia o seu, e ele acaba substituindo-o.

   Não sei ao certo em que ponto, ou como, você está lançando seu agente ssh, mas se o gerenciador de área de trabalho iniciar um após o seu, suas variáveis exportadas substituirão as que você criou.

2. Seu gerenciador de desktop está lançando seu próprio agente ssh antes do seu, e o seu não está sendo mantido.

   Se você estiver apenas iniciando uma janela de terminal e fazendo eval $(ssh-agent); ssh-add , as variáveis exportadas por esse ssh-agent não persistirão depois que você fechar a janela do terminal. Depois de iniciar uma nova janela de terminal, você obterá as variáveis definidas pelo agente ssh lançadas pelo gerenciador de área de trabalho.

A maneira como o ssh-agent funciona é que ele inicia um daemon em segundo plano e depois imprime várias variáveis que precisam ser configuradas.

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-JLbBwVBP4754/agent.4754; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4755; export SSH_AGENT_PID;
echo Agent pid 4755;

Então, quando você eval $(ssh-agent) , você está apenas definindo todas essas variáveis.

Agora, as variáveis são herdadas apenas por crianças, portanto, para que elas persistam no gerenciador de desktop, elas precisam ser definidas antes do início do gerenciador da área de trabalho. Isso pode ser difícil de acertar e varia entre distros. É por isso que muitos gerentes de desktop fazem isso por si mesmos.
Observe que isso também é feito algumas vezes durante a inicialização da pilha de pam.

    

Answer 2

Como Patrick salienta, é provável que o seu ssh-agent concorra com uma instância gerada pelo seu ambiente de área de trabalho. Bem, competir provavelmente não é a palavra certa - as variáveis que permitem que outros aplicativos conversem com o agente devem estar em seu ambiente. Como todos os aplicativos da sua área de trabalho são gerados de alguma forma por alguma parte do ambiente de área de trabalho (suponha que seja o gerenciador de sessões), primeiro você precisa colocar as variáveis na lista de ambiente do gerenciador de sessões. Isso pode acontecer de duas maneiras:

1. o gerenciador de sessão faz isso internamente (dependendo de alguma opção definida em algum lugar). Isso incluiria o agente sendo gerado por um módulo PAM (chamado do gerenciador de login / sessão).

2. através de um script de usuário como o seu. No entanto, isso não é tão simples quanto parece. Quando o gerenciador de sessões executa seu script, ele cria um novo processo - o interpretador de scripts. Em seu ambiente, as variáveis são definidas, mas não podem ser facilmente exportadas de volta para o gerenciador de sessões - seu processo pai. Isso é equivalente a fazer o mesmo em seu shell - executar o script não terá efeito algum no ambiente do shell atual. Você teria que source it - então os comandos seriam executados pelo shell atual, dando-lhe acesso às variáveis atualizadas / criadas. Isso seria bastante complicado de se fazer no gerenciador de sessão (já que não é um interpretador de shell). Portanto, seu ssh-agent não está realmente competindo. Ele fica lá com identidades carregadas por ssh-add do seu script e ninguém realmente sabe disso.

Para ter uma ideia do que está acontecendo, verifique a saída de ¹

ps fax | grep -E "(ssh|gpg)-[a]gent"

e mude o seu script para

echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK" > ~/ssh-agent.stdout
echo "SSH_AGENT_PID=$SSH_AGENT_PID" >> ~/ssh-agent.stdout
eval 'ssh-agent | tee -a ~/ssh-agent.stdout'

Isso imprimirá o conteúdo das variáveis no arquivo ~/ssh-agent.stdout e, em seguida, adicionará a saída de ssh-agent nesse mesmo local antes de processá-lo (e, assim, exportar as variáveis). Compare o conteúdo do arquivo com as variáveis de ambiente SSH_AUTH_SOCK e SSH_AGENT_PID , por exemplo, em um terminal do shell recém-criado. Na maioria dos casos, você será capaz de dizer qual deles foi iniciado primeiro, já que os PIDs estão (ciclicamente) crescendo monotonamente. A parte gpg-agent está lá porque alguns DEs usam a capacidade de gpg-agent para fornecer serviços de agente SSH também.

Você também pode remover essa linha chamando ssh-agent completamente - se o seu script estiver sendo executado após o agente SSH gerar seu ambiente de área de trabalho, você obterá a caixa de diálogo de senha (para o agente certo), já que as variáveis de ambiente Estará presente. Se não, significa que seu script está sendo executado antes da instância do agente do DE e, portanto, não tem acesso a nenhum agente.

¹ os colchetes são um para remover o grep da lista de processos.