Por que não consigo interagir com meu agente ssh? (por exemplo, ssh-add -D não funciona) O

Question

No meu sistema Kubuntu 14.04 estou tentando gerenciar chaves com meu agente SSH, mas de alguma forma parece ignorar meus comandos ssh-add . Veja isso abaixo e você verá o que quero dizer.

1. Relacione as chaves atuais

   ⟫ ssh-add -l
   2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)
   

   Essa chave é carregada no momento da inicialização, mas eu esperava alguma chave ECDSA, não RSA. Eu não sei essa chave ...

2. Remova a chave do agente.

   ⟫ ssh-add -D
   All identities removed.
   

   yey! Mas ... é isso?

   ⟫ ssh-add -l
   2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)
   

   Que diabos? Apenas mentiras para mim.

3. O que está acontecendo aqui?

   ⟫ env | grep -i ssh
   SSH_AUTH_SOCK=/run/user/1000/keyring-eDJggO/ssh
   

   Vamos ver qual processo está executando esse soquete.

   ⟫ sudo fuser -u /run/user/1000/keyring-eDJggO/ssh
   [sudo] password for gert: 
   /run/user/1000/keyring-eDJggO/ssh:  9434(gert)
   ⟫ ps -p 9434 u
   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   gert      9434  0.0  0.0 292528  7192 ?        Sl   00:05   0:00 gnome-keyring-daemon [...]
   

   Que diabos o keyring do GNOME está fazendo no meu sistema KDE? A carteira do KDE não deveria ser meu agente SSH aqui?

Isso leva a mais perguntas do que respostas e fico com um agente ssh não funcional.

Em outro sistema, não observo esse comportamento e não consigo encontrar uma diferença de configuração. Ambos possuem apenas o KDE instalado e os pacotes instalados são quase idênticos (gerenciados pelo Puppet).

    

Answer 1

NOTA: não é uma resposta para resolver o problema raiz. Por favor, forneça uma nova resposta se você acha que pode resolver a causa raiz. Você realmente tem que ler porque minha solução é apenas um hack feio.

Aqui está uma explicação sobre o que acontece no momento da inicialização, identificando o culpado.

Usando o KDM (ou LightDM) como gerenciador de login, uma sessão X é gerada ao fazer login. O gerenciador de login permite que você selecione uma sessão X (por exemplo, GNOME, KDE Plasma, etc.) com base naqueles disponíveis. no seu sistema. O diretório /usr/share/xsessions contém os arquivos para cada um desses ambientes de área de trabalho instalados e sua opção específica do usuário é salva em ~/.dmrc .

Enquanto o ambiente da área de trabalho é carregado após o login, ele carrega todos os scripts em /etc/X11/Xsession.d/ . Em um sistema Kubuntu 14.04 eu vejo /etc/X11/Xsession.d/90x11-common_ssh-agent lá por padrão, inicializando um agente SSH. Como esperado. Ótimo!

Na prática, no entanto, vemos coisas diferentes. De onde vem gnome-keyring-daemon e por que o ssh-agent normal não é iniciado? Bem, o chaveiro do GNOME é iniciado de duas maneiras:

• Início automático do XDG, em /etc/xdg/autostart/gnome-keyring-ssh.desktop
• Como um trabalho de sessão do Upstart em /usr/share/upstart/sessions/gnome-keyring.conf

Todos os scripts estão primeiro verificando os valores do ambiente se eles continuarão. Por exemplo,

[ -z "$SSH_AUTH_SOCK" ] || [ -z "$GPG_AGENT_INFO" ] || { stop; exit 0; }

Isso torna uma espécie de condição de corrida que o agente SSH é realmente iniciado. O primeiro ganha. Prepare-se para mais bits desagradáveis.

Como funciona em uma máquina confiável e não confiável em outra? As tarefas de inicialização de sessão X só são iniciadas quando a variável de ambiente DESKTOP_SESSION é colocada na lista de permissões para ela em /etc/upstart-xsessions , manipulada por /etc/X11/Xsession.d/00upstart . O KDM permite definir um ambiente de desktop 'Padrão' ( default em ~/.dmrc ), efetivamente kde-plasma , mas não aparecendo kde-plasma .

com Session=kde-plasma :

⟫ echo $DESKTOP_SESSION
kde-plasma

Com Session=default em uma área de trabalho do KDE Plasma:

⟫ echo $DESKTOP_SESSION
default

Isso está totalmente errado. E você pode adivinhar agora por que ele falha na verificação da lista branca em relação a /etc/upstart-xsessions .

Correção rápida para a execução da sessão de terminal

killall gnome-keyring-daemon && eval 'ssh-agent'

Conclusão

Parece que se pode encontrar um bug com todos os trabalhos de sessão do Upstart não sendo iniciados. Outro bug impede a interface adequada com o agente SSH do conjunto de chaves do GNOME (ou ssh-add deve reclamar e falhar). Oh eu te odeio, bugs.

Uma vez que eu encontre tempo para fazer uma pesquisa sobre o que exatamente deve fazer o quê, eu vou arquivar os relatórios de bugs.

Por enquanto, decidi apenas 'usar' o bug do Upstart e impedir que os jobs da sessão do Upstart fossem executados definindo Session=default . Eu não sei o quanto isso quebra, mas até agora não vi nada desmoronando.

A causa raiz é a aparência do anel de chaves do GNOME em primeiro lugar e que não deve mentir para mim e continuar oferecendo as chaves erradas.

    

Answer 2

Eu sempre acabo sudo apt-get remove - limpar gnome-keyring de qualquer maneira, seguido de um reinício. O ubuntu-sso depende disso, mas eu não uso isso, então não se preocupe.

O ssh-agent parece funcionar como deveria depois.

    

Answer 3

Eu percebo que este é um tópico antigo. Eu estou usando o xubuntu 16.04. Parece que o bug ainda está lá. Eu instalei cavalos-marinhos para administrar as chaves e isso funcionou.