Existe uma razão técnica pela qual o ssh-agent não possui um recurso de inatividade / tempo limite inativo do tipo sudo?


9

Há algumas breves discussões sobre o ssh-agent -trecurso existente em [1], e houve um post já em 2001 no debian-devel [2] desejando um recurso de tempo limite de inatividade. Há uma discussão semelhante aqui no SE [3] para concurso.

Eu tenho que me perguntar como o resto do planeta está protegendo as chaves ssh - estou perdendo algo óbvio para que isso seja um ponto de dor para mim e, aparentemente, mais ninguém? Especificamente, estou pensando em interações ssh com script, como com ansible. Parece que hoje, suas escolhas são:

  • Defina a vida útil da sua chave no agente por um período preocupantemente longo, por exemplo. 1 h ou qualquer que seja o tempo máximo de execução dos seus scripts (duvido que muitas pessoas permitam que o tempo limite de re-autenticação do sudo se estenda por tanto tempo!) - mas seahorse/ gnome-keyring-daemonquase nem suporta isso tanto [4]
  • Cuide de seus scripts de execução prolongada e continue digitando sua senha a cada 5/10/15 minutos: agora você pode ser facilmente assistido digitando sua senha 20 vezes por dia
  • Hackeie sua própria solução caseira para imitar esse recurso ausente, talvez em conjunto com o TMOUTshell var do seu shell (obrigado pessoal no freenode #openssh IRC pela sugestão)
  • Não tenha um tempo de vida útil da chave definido, ou seja, seu agente mantém sua chave carregada para sempre ou até você matar / reiniciar

Se você estiver usando breves tempos limite do agente ssh, frases secretas fortes e arquivos-chave diferentes para cada tipo de função que você autentica: isso leva a um dia muito frustrante!

Eu experimentei gpgkey2ssh e cartões inteligentes, mas isso realmente não resolve esse problema em particular: eu ainda quero a funcionalidade ssh-agent e não preciso me autenticar novamente a cada 5 minutos apenas para impedir que minhas chaves privadas sejam expostas na memória enquanto meu computador está ocioso.

Estou fazendo errado?

[1] Configurando o tempo limite padrão para o agente SSH

[2] https://lists.debian.org/debian-devel/2001/09/msg00851.html

[3] /server/518312/putty-pageant-forget-keys-after-period-of-inactivity

[4] https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/129231


1
Não é uma resposta, mas sim, existem alguns desafios técnicos sobre como detectar a inatividade da sessão quando ssh-agenté independente do tipo de sessão em que faz parte (por exemplo, sessão tty, sessão X11 ou outra coisa). A única coisa que gostaria de dizer se seus scripts automatizados provavelmente não deveriam depender da chave carregada no seu agente. Provavelmente, cada um deve ter sua própria chave privada, que é autorizada por meio de comandos forçados nos servidores apropriados para executar apenas os comandos remotos específicos que cada script precisa executar. Isso, claro, deixá-lo correr os de cron etc ...
Celada

Não espero ssh-agentsaber quando uma sessão está inativa, mas pelo menos inicie o tempo limite a partir do momento em que a última operação de assinatura ocorreu, não apenas quando ssh-agentfoi iniciada. Além disso, eu já uso contas de usuário e arquivos-chave separados para cada função de script, sudoers permite que apenas 1 ou 2 comandos sejam sudo'd, se necessário, e procurei lshellbloquear ainda mais as coisas. Mas tudo isso ainda não me isenta de precisar proteger meus arquivos de chave: apenas porque sudo zfs sendé o único comando permitido para uma determinada chave, esse é um comando bastante poderoso para quem usa essa chave!
precisa saber é o seguinte

Outra solução alternativa: use as opções ControlMaster/ ControlPath/ ControlPersist(consulte man ssh_config) para seu script. Pelo menos se estiver apenas se conectando a um host.
Derobert 24/04

Essa é uma sugestão interessante e me ensinou alguma coisa (obrigado!), Mas não parece resolver nada se eu ainda ssh-agentmanter minhas chaves carregadas até reiniciar (o que pode levar semanas).
csirac2

Respostas:


2

Se isso lhe interessa, você pode facilmente usar a xscreensaver-command -watchinterface para executar ssh-add -Dquando a tela estiver bloqueada. Verifique a página do manual para um exemplo muito simples.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.