Por qué ssh falla de crontab pero succedes cuando se ejecuta desde una línea de comandos?

StackOverflow https://stackoverflow.com/questions/869589

  •  22-08-2019
  •  | 
  •  

Pregunta

Tengo un script en bash que hace ssh a una máquina remota y ejecuta un comando como:

ssh -nxv user@remotehost echo "hello world"

Cuando ejecuto el comando desde la línea de comando funciona bien, pero falla cuando se ejecuta como parte de crontab (errorcode=255 - no puede establecer una conexión SSH).Detalles:

...
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.
...

Cuando se ejecuta localmente estoy actuando como una raíz, crontab funciona como root así.Ejecutar 'id' desde el crontab de la línea de comandos y nos da exactamente el mismo resultado:

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

Hago ssh desde algunos de los locales de la máquina a la máquina que ejecuta crond.Tengo la clave ssh y credenciales ssh para crond de la máquina y cualquier otra máquina a la que las secuencias de comandos que se conecta.

PS.Por favor, no preguntar/queja/comentario de que la ejecución de cualquier cosa como root es malo/malo/etc - no es el propósito de esta pregunta.

¿Fue útil?

Solución

Supongo que normalmente cuando SSH desde el equipo local para la máquina que ejecuta crond, su clave privada se carga en ssh-agent y enviada sobre la conexión. Así que cuando se ejecuta el comando desde la línea de comandos, que encuentra su clave privada en ssh-agent y lo utiliza para iniciar sesión en el equipo remoto.

Cuando crond ejecuta el comando, que no tiene acceso a ssh-agent, por lo que no puede utilizar su clave privada.

Usted tendrá que crear una nueva clave privada para el usuario root en el crond funcionamiento de la máquina, y copiar la parte pública de la misma al archivo correspondiente authorized_keys en la máquina remota que desea crond para iniciar sesión en.

Otros consejos

keychain

resuelve esto en una forma indolora.Está en los repositorios de Debian/Ubuntu:

sudo apt-get install keychain

y tal vez para muchas otras distribuciones (parece que se originó a partir de Gentoo).

Este programa se iniciará un ssh-agent si ninguno está funcionando, y proporcionar secuencias de comandos de shell que puede ser sourced y conecte el shell actual a este particular ssh-agent.

Para bash, con una clave privada denominada id_rsa, añada lo siguiente a su .profile:

keychain --nogui id_rsa

Esto iniciará una ssh-agent y añadir el id_rsa clave en el primer inicio de sesión después de reiniciar el sistema.Si la clave es la frase de contraseña-protegida, se le pedirá la contraseña. No hay necesidad de utilizar sin protección claves más! Para inicios de sesión posteriores, se reconocerá que el agente y que no le pida una contraseña de nuevo.

Asimismo, agregue el siguiente como una última línea de su .bashrc:

. ~/.keychain/$HOSTNAME-sh

Esto permitirá a la shell saber donde para llegar a la SSH agente administrado por keychain.Asegúrese de que .bashrc se obtiene de .profile.

Sin embargo, parece que cron los trabajos todavía no se ve esto.Como remedio, que incluya la línea de arriba en la crontab, justo antes de su actual comando:

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

No exponga sus claves SSH sin contraseña. Usar ssh-cron lugar, lo que le permite programar tareas mediante agentes SSH.

Así que tuve un problema similar. Vine aquí y vi varias respuestas, pero con un poco de experimentación aquí es cómo lo conseguí trabajo con sshkeys con frase de contraseña, ssh-agent y cron.

En primer lugar, mi configuración SSH utiliza el siguiente script en mi escritura del golpe de inicio. 

# 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

Cuando me conecto, ingreso mi contraseña una sola vez y luego de ahí en adelante se utilizará ssh-agent me autenticar automáticamente.

Los detalles ssh-agente se mantienen en .ssh / medio ambiente. Esto es lo que el guión se verá así: 

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

En cuanto a cron, se puede configurar un trabajo como un usuario regular de varias maneras. Si ejecuta crontab -e como usuario root se configurará un cron usuario root. Si ejecuta como crontab -u Davis -e que se sumará una tarea programada como identificador de usuario Davis. Del mismo modo, si se ejecuta como usuario Davis y qué crontab -e se va a crear una tarea programada que se ejecuta como identificador de usuario Davis. Esto se puede verificar con la siguiente entrada: 

30 *  *   *   *     /usr/bin/whoami

Esto le enviará por correo el resultado de whoami cada 30 minutos a Davis usuario. (Hice un -e crontabe como usuario Davis.)

Si intenta ver qué teclas se utilizan como usuario Davis, hacer esto: 

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

Se va a fracasar, el registro enviado por correo dirá 

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

Could not open a connection to your authentication agent.

La solución es a la fuente de la secuencia de comandos env para ssh-agente anteriormente. Aquí está la entrada cron resultante: 

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

Esto ejecutará la secuencia de comandos a las 10:55. Note el líder. en el guión. Se dice que para ejecutar este script en mi entorno similar a lo que está en el guión .bash init.

Ayer tuve problema similar ...

Tengo trabajo cron en un servidor, el cual se inicia alguna acción en otro servidor, usando ssh ... El problema era que los permisos de usuario y claves ...

en el crontab tuve 

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

Y simplemente no funcionaba (ni tienen permisos). I tryed para ejecutar cron como usuario específico, que está conectado a otro servidor 

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

Pero sin efecto.

Por último, i navicate al guión y luego ejecutar el archivo php, y funcionó .. 

* * * * * cd /path/to/script/; php doSomeJob.php
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top