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

Question

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

Could not open a connection to your authentication agent

Estamos executando ssh em alguns scripts bash.

Depois de analisar a ampla variedade de coisas que podem levar a esse erro, deparei com essa solução:

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

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

Antes de executar esses dois comandos, as variáveis env não são configuradas em um terminal:

$ echo $SSH_AGENT_PID

$ echo $SSH_AUTH_SOCK

$ 

Depois de executar os comandos, as variáveis env são definidas como esperado. No entanto, eles não permanecem definidos (por exemplo, em um shell diferente ou após a reinicialização).

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

Eu vejo essa informação na página man, mas ela não me diz como o Ubuntu está configurando o agente automaticamente ou o que está acontecendo na máquina do meu amigo, então isso não está funcionando para ele.

There are two main ways to get an agent set up: The first is that the agent starts a new subcommand into which some environment variables are exported, eg ssh-agent xterm &. The second is that the agent prints the needed shell commands (either sh(1) or csh(1) syntax can be generated) which can be evalled in the calling shell, eg eval ssh-agent -s for Bourne-type shells such as sh(1) or ksh(1) and eval ssh-agent -c for csh(1) and derivatives.

Depois de instalar acct e reinicializar, 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

Da página do manual:

F -- command executed after a fork but without a following exec

Não tenho certeza se isso é significativo.

    

Answer 1

Você mencionou que seu usuário está ssh ing, não fazendo login localmente. Portanto, o use-ssh-agent em /etc/X11/Xsession.options é um arenque vermelho: ele não será executado em sessões SSH, somente ao efetuar logon em uma área de trabalho da GUI X11 localmente (ou usando alguma sessão X11 virtual como em VNC ou RDP).

Em vez disso, você deve verificar se libpam-ssh está instalado em 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 especificamente a chave em ~/.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 a frase secreta for igual à senha de login do usuário. Estou pensando que isso pode ser a causa do comportamento diferente entre seus sistemas.

    

Answer 2

Você mencionou que

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

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

    

Answer 3

Para o

$ eval 'ssh-agent -s'

construir para trabalhar quando colocar em um "script de inicialização", sua sessão e, finalmente, o terminal onde você espera que o ambiente, deve ser descendentes (por fork e exec ) desse script. A razão é que a saída de ssh-agent -s , quando avaliada, define o ambiente variáveis no shell chamando eval . Formar lá, eles podem ser passados, e eles podem ser perdidos no caminho também.

Então, se ssh-agent for executado pelo script A em algum lugar durante o login, mas o terminal B no qual você inicia seu script de shell é não um descendente de A, então você não pode ver o ambiente em B.

Se você tiver ssh-agent iniciado como systemd --user service, então você pode ter que 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, meu ~/.config/systemd/user/ssh-agent.service é 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 ~/.profile eu tenho a linha

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

Observe que %t no primeiro corresponde a ${XDG_RUNTIME_DIR} em o último.

Observação: não estou feliz com isso!

    

Answer 4

Encontrei a resposta aqui:

link

No ubuntu, o utilitário ssh-add não carrega os arquivos de certificado. Ocorre quando o agente é aquele 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 então inicia o gnome-keyring-ssh.desktop, o que faz com que o AUTH_SOCKET retome, podemos voltar ao ssh-agent original desabilitando o gnome-keyring-ssh.desktop.

Desativar 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-a e reinicialize:

X-GNOME-Autostart-enabled=false