ssh-agent não está sendo configurado (SSH_AUTH_SOCK, SSH_AGENT_PID env vars não configurados)

Eu configurei uma nova conta de usuário para um amigo no Kubuntu 12.04. Quando ele usa, sshele recebe este erro:

Não foi possível abrir uma conexão com seu agente de autenticação

Estamos executando sshalguns scripts bash.

Depois de analisar a grande variedade de coisas que podem levar a esse erro, me deparei com esta solução:

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Em seguida, ele pode executar os sshcomandos (e bash scripts) conforme o esperado.

Antes de executar esses dois comandos, as variáveis ​​env não estão definidas em um terminal:

$ echo $SSH_AGENT_PID

$ echo $SSH_AUTH_SOCK

$ 

Após a execução dos comandos, as variáveis ​​env são definidas conforme o esperado. No entanto, eles não permanecem definidos (por exemplo, em um shell diferente ou após a reinicialização).

Quero saber como configurar seu computador para que ele não precise executar esses dois comandos para definir as variáveis ​​env. Não preciso executá-los no meu computador (sempre). Até agora não estou vendo o que há de diferente entre nossas máquinas.

Eu vejo essas informações na página de manual, mas não me diz como o Ubuntu normalmente está configurando o agente automaticamente ou o que está acontecendo na máquina do meu amigo para que isso não funcione para ele.

Existem duas maneiras principais de configurar um agente: A primeira é que o agente inicia um novo subcomando para o qual algumas variáveis ​​de ambiente são exportadas, por exemplo, ssh-agent xterm &. A segunda é que o agente imprime os comandos necessários do shell (pode ser gerada a sintaxe sh (1) ou csh (1)) que pode ser avaliada no shell de chamada, por exemplo, eval ssh-agent -spara shells do tipo Bourne, como sh (1) ou ksh (1) e eval ssh-agent -cpara csh (1) e derivados.

Após instalar accte reiniciar, esta é a saída de lastcomm:

ssh-agent         F    newuser __         0.12 secs Wed Aug  7 11:02
ssh-agent         F    newuser __         0.00 secs Wed Aug  7 20:34
ssh-agent         F    newuser __         0.02 secs Wed Aug  7 20:02
ssh-agent         F    newuser __         0.01 secs Thu Aug  8 12:39
ssh-agent         F    newuser __         0.02 secs Thu Aug  8 07:45

Na página do manual:

F - comando executado após um fork, mas sem o seguinte exec

Não tenho certeza se isso é significativo.

Você mencionou que seu usuário está sshentrando, não efetuando login localmente. Portanto, o use-ssh-agentin /etc/X11/Xsession.optionsé um arenque vermelho: ele não será executado em sessões SSH, apenas ao fazer logon em uma área de trabalho da GUI do X11 localmente (ou usar alguma sessão do X11 virtual, como no VNC ou RDP).

Em vez disso, você deve verificar se libpam-sshestá instalado em qualquer um dos sistemas. Ele pode ser configurado para autenticar um usuário usando senhas de chave privada SSH, mas isso é opcional e você precisará colocar a chave especificamente ~/.ssh/login-keys.d/para essa funcionalidade.

Seu outro recurso, no entanto, é iniciar automaticamente um agente SSH em qualquer sessão de login e adicionar automaticamente chaves privadas SSH ao agente se sua senha é a mesma que a senha de login do usuário. Eu estou pensando que isso pode ser a causa do comportamento diferente entre seus sistemas.

Para o

$ eval `ssh-agent -s`

Construa para funcionar quando colocado em um "script de inicialização", sua sessão e, finalmente, o terminal em que você espera o ambiente, devem ser descendentes (por forke exec) desse script. O motivo é que a saída de ssh-agent -s, quando avaliada, define variáveis ​​de ambiente na chamada do shelleval . Lá, eles podem ser transmitidos e perdidos no caminho.

Portanto, se ssh-agentfor executado pelo script A em algum lugar durante o login, mas o terminal B no qual você iniciar o shell script não for um descendente de A, não será possível ver o ambiente em B.

Se você ssh-agentiniciou como systemd --userserviço, talvez seja necessário usar a convenção: não deixe ssh-agent especificar as variáveis, mas use o conhecimento comum ao iniciar o agente e ao iniciar a sessão. Por exemplo, minha ~/.config/systemd/user/ssh-agent.serviceaparência é assim:

[Unit]
Description=SSH agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

E no meu ~/.profileeu tenho a linha

export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Observe que %tno primeiro corresponde ao ${XDG_RUNTIME_DIR}segundo.

Nota: Não estou feliz com isso!

Encontrei a resposta aqui:

http://www.bernatchez.net/userauth.html

No ubuntu, o utilitário ssh-add falha ao carregar arquivos de certificado. Ocorre quando o agente é o implementado pelo gnome-keyring. A correção é parar de usar o componente ssh do gnome-keyring. Como o processo de inicialização realmente inicia um verdadeiro ssh-agent e, em seguida, inicia o gnome-keyring-ssh.desktop que derruba o AUTH_SOCKET para assumi-lo, podemos voltar ao ssh-agent original desativando o gnome-keyring-ssh.desktop.

Desative o gnome-keyring-ssh.desktop:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Adicione a seguinte linha ao arquivo da área de trabalho, salve-o e reinicie:

X-GNOME-Autostart-enabled=false

Você mencionou isso

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

funciona como desejado. Então, você só precisa que eles sejam executados no momento certo, em .bash_profile ou .xsession. Adicione instruções de depuração como (date; env|sort) >> /tmp/logpara ajudar você a entender exatamente quando elas são executadas.