☰

Permissão ssh negada apenas no cron job

tag-icon • tag-icon bash ssh cron
Permissão ssh negada apenas no cron job

Tendo um problema muito estranho. Eu criei um pequeno script bash que executa um comando em um host remoto via ssh (usando autenticação de chave pública).

Quando executo este script manualmente na linha de comando, ele funciona bem, mas quando colocado em /etc/cron.hourly ele falha com Permission denied, please try again.erro.

  • Defino explicitamente a chave no script usando ssh -i /root/.ssh/id_rsa user@remote "command";
  • o script está sendo executado como root (adicionei um echo `id` > /tmp/whoami.logpara verificar novamente); e
  • a chave ssh não é protegida por senha ...

O sistema é o servidor Ubuntu 12.04, não tenho muito acesso remoto para solucionar problemas, mas como disse, executar o ssh manualmente ou o mesmo script bash da linha de comando funciona.

Alguma ideia de por que isso está acontecendo ou como consertar?

atualizar

Acontece que eu estava enganado e a chave ssheraprotegido por senha (com o chaveiro carregando o agente ssh), por isso ele falhou em um script, mas não ao executar a partir da sessão bash. Adicionar . ~/.keychain/$HOSTNAME-shao meu script resolveu o problema (graças a @grawity que me indicou a direção certa e forneceu uma resposta abrangente).

Responder1

Comandos interativos e cron jobs são executados em diferentes ambientes – em particular,uma sessão interativa pode ter um agente SSH em execução ou um Kerberos TGT armazenado.Devido à forma como sshos métodos de autenticação dos pedidos, vocênão podecertifique-se de que sua chave seja usada apenas porque você adicionou a -iopção.

  • Se um agente SSH estiver em execução, o sshcliente sempre tentará as chaves do agenteantesusando quaisquer chaves especificadas explicitamente.

  • Se a rede usar Kerberos e um Kerberos TGT estiver presente, o OpenSSH irá usá-loantestentando autenticação de chave pública.

Não sei nada sobre o seu ambiente, mas ambas as possibilidades são fáceis de verificar:

  1. Adicione unset SSH_AUTH_SOCKe unset KRB5CCNAMEantes do sshcomando,entãoexecute manualmente o script modificado.

    Isso impedirá que o script veja o agente ou os tickets Kerberos e usará apenas a chave especificada explicitamente.

  2. Adicione a -vopção a ssh. Isso exibirá mais detalhes sobre como a autenticação acontece.

Você também pode adicionar -oIdentitiesOnly=yesao sshcomando; Isso vaiforçá-lo a usar a chave especificada.

E se você adicionar dicas sobre como acessar o agente do cron - melhor ainda

Geralmente, isso não é recomendado, pois o agente geralmente está intimamente ligado à sua sessão de login interativa. Em particular, ele só é iniciado quando você faz login e é encerrado quando você sai – e precisa de sua senha para realmente desbloquear as chaves SSH (supondo que elas sejam protegidas por senha).

Você mencionou "Keychain" - este é o programa OS X ou o script Linux? (Não sei muito sobre a arquitetura do Mac OS X, mas AFAIK faz com que sejamuitomais difícil acessar o agente ssh do usuário a partir de um cronjob...)

Responder2

Outra solução alternativa para esse problema é definir cron como ssh na caixa local para, por sua vez, executar o comando ssh em vez de executar o arquivo ou comando por seu caminho local absoluto. Isso armazena em cache o KRB5CCNAME e funciona onde /path/command não funciona.

# Fails:
0 * * * * /home/user/sshscript.sh

# Works:
0 * * * * /usr/bin/ssh user@localhost /home/user/sshscript.sh

#!/bin/bash
# Works:
unset SSH_AUTH_SOCK
unset KRB5CCNAME
/usr/bin/ssh user@localhost /home/user/sshscript.sh

Responder3

Você pode usarssh-cronpara configurar conexões SSH agendadas para servidores seguros sem expor suas chaves SSH, mas usando o agente SSH.

Responder4

você pode executar seu script ou comando no crontab como:

0 * * * * bash -c -l "/home/user/sshscript.sh"

ou

0 * * * * bash -c -l "ssh root@seuhost 'echo $HOSTNAME'"

informação relacionada