Por ssh falha de crontab mas succedes quando executado a partir de uma linha de comando?

Question

Eu tenho um script que faz o ssh para uma máquina remota e executa um comando ali, como:

ssh -nxv user@remotehost echo "hello world"

Quando eu executar o comando a partir de uma linha de comando que funciona bem, mas falha quando está sendo executado como parte do crontab (errorcode = 255 - não pode estabelecer uma conexão SSH). Detalhes:

...
Waiting for server public key.
Received server public key and host key.
Host 'remotehost' is known and matches the XXX host key.
...
Remote: Your host key cannot be verified: unknown or invalid host key.
Server refused our host key.
Trying XXX authentication with key '...'
Server refused our key.
...

Ao executar localmente eu estou agindo como uma raiz, obras crontab como root também. Executando 'id' de crontab e linha de comando dá exatamente o mesmo resultado:

$ id
> uid=0(root) gid=0(root) groups=0(root),...

Eu faço ssh a partir de uma máquina local para o crond máquina em funcionamento. Tenho chave ssh e credenciais para ssh a máquina crond e qualquer outra máquina que os scripts se conecta.

PS. Por favor, não pergunte / reclamar / comentário que a execução de tudo como usuário root é ruim / errado / etc - não é o propósito desta questão

.

Answer 1

Eu estou supondo que normalmente quando você ssh a partir de sua máquina local para o crond máquina rodando, sua chave privada é carregado em ssh-agent e encaminhado através da conexão. Então, quando você executar o comando a partir da linha de comando, ele encontra sua chave privada em ssh-agente e usa-lo para fazer logon no computador remoto.

Quando executa o comando crond, que não tem acesso ao ssh-agent, por isso não pode usar sua chave privada.

Você terá que criar uma nova chave privada para o root na máquina que executa crond, e copiar a parte pública do que para o arquivo authorized_keys apropriado na máquina remota que deseja crond para login.

Answer 2

keychain

resolve isso de uma maneira indolor. É nos repositórios do Debian / Ubuntu:

sudo apt-get install keychain

e, talvez, para muitas outras distros (parece que se originou a partir de Gentoo).

Este programa irá iniciar um ssh-agent se nenhum está em execução, e fornecer shell scripts que podem ser sourced e conecte o shell atual para este ssh-agent particular.

Para bash, com uma chave chamada id_rsa privada, adicione o seguinte ao seu .profile:

keychain --nogui id_rsa

Isto irá iniciar um ssh-agent e adicionar a chave id_rsa no primeiro logon após a reinicialização. Se está protegido frase secreta-chave, que também irá pedir a senha. Não há necessidade de usar teclas desprotegidos mais! Para logins subseqüentes, ele irá reconhecer o agente e não pedir uma senha novamente.

Além disso, adicione o seguinte como uma última linha de seu .bashrc:

. ~/.keychain/$HOSTNAME-sh

Isso permitirá que o know shell onde para alcançar o agente SSH gerido por keychain. Certifique-se que .bashrc é proveniente de .profile.

No entanto, parece que os empregos cron ainda não vê isso. Como um remédio, incluir a linha acima no crontab, pouco antes de seu comando real:

* * * * * . ~/.keychain/$HOSTNAME-sh; your-actual-command

Answer 3

Não exponha suas chaves SSH sem senha. Use ssh-cron em vez disso, o que lhe permite agendar tarefas usando agentes SSH.

Answer 4

Então, eu tive um problema semelhante. Eu vim aqui e vi várias respostas, mas com algumas experiências aqui é como eu consegui trabalhar com sshkeys com senha, ssh-agente e cron.

Primeiro, a minha configuração ssh utiliza o seguinte script no meu script bash inicialização.

# JFD Added this for ssh
SSH_ENV=$HOME/.ssh/environment

    # start the ssh-agent
    function start_agent {
        echo "Initializing new SSH agent..."
        # spawn ssh-agent
        /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
        echo succeeded
        chmod 600 "${SSH_ENV}"
        . "${SSH_ENV}" > /dev/null
        /usr/bin/ssh-add
    }


    if [ -f "${SSH_ENV}" ]; then
         . "${SSH_ENV}" > /dev/null
         ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
            start_agent;
        }
   else
        start_agent;
   fi

Quando eu entrar, eu entrar na minha senha uma vez e, em seguida, a partir de então ele irá usar ssh-agente para me autenticar automaticamente.

Os detalhes ssh-agente são mantidos em .ssh / environment. Aqui está o que esse script será parecido com:

SSH_AUTH_SOCK=/tmp/ssh-v3Tbd2Hjw3n9/agent.2089; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2091; export SSH_AGENT_PID;
#echo Agent pid 2091;

Em relação cron, você pode configurar um trabalho como um usuário regular de várias maneiras. Se você executar crontab -e como usuário root ele vai configurar um cron usuário root. Se executar como crontab -u davis -e ele irá adicionar um trabalho cron como davis UserID. Da mesma forma, se você executar como usuário davis e fazer crontab -e ele irá criar um trabalho cron que é executado como ID de usuário davis. Isto pode ser verificado com a seguinte entrada:

30 *  *   *   *     /usr/bin/whoami

Isto irá enviar o resultado de whoami cada 30 minutos para usuário davis. (Eu fiz a -e crontabe como usuário davis.)

Se você tentar ver o que as teclas são usadas como usuário davis, faça o seguinte:

36 *  *   *   *     /usr/bin/ssh-add -l

Ele irá falhar, o log enviados por correio dirá

To: davis@xxxx.net
Subject: Cron <davis@hostyyy> /usr/bin/ssh-add -l

Could not open a connection to your authentication agent.

A solução é a fonte do script env para ssh-agente acima. Aqui é a entrada cron resultante:

55 10  *   *   *     . /home/davis/.ssh/environment; /home/davis/bin/domythingwhichusesgit.sh

Isto irá executar o script às 10:55. Observe a liderança. no script. Ele diz para executar este script no meu ambiente semelhante ao que está no script de inicialização .bash.

Answer 5

Ontem eu tive problema semelhante ...

Eu tenho trabalho cron em um servidor, que começar alguma ação em outro servidor, usando ssh ... O problema era permissões de usuário e chaves ...

em I crontab estiveste

* * * * * php /path/to/script/doSomeJob.php

E ele simplesmente não funcionou (não tinha permissões). Eu tentei executar cron como usuário específico, que está ligado a outro servidor

* * * * * user php /path/to/script/doSomeJob.php

Mas sem efeito.

Finalmente, eu navicate de script e, em seguida, executar o arquivo php, e funcionou ..

* * * * * cd /path/to/script/; php doSomeJob.php