Permiso ssh denegado solo en trabajo cron

Tener un problema muy extraño. Creé un pequeño script bash que ejecuta un comando en un host remoto a través de ssh (usando la autenticación de clave pública).

Cuando ejecuto este script manualmente desde la línea de comando, funciona bien, pero cuando se coloca en /etc/cron.hourly falla con Permission denied, please try again.error.

• Establezco explícitamente la clave en el script usando ssh -i /root/.ssh/id_rsa user@remote "command";
• el script se está ejecutando como root (agregué una echo `id` > /tmp/whoami.logpara verificar dos veces ); y
• la clave ssh no está protegida con contraseña ...

El sistema es el servidor Ubuntu 12.04, no tengo mucho acceso en el lado remoto para solucionar problemas, pero como dije, ejecutar ssh manualmente o el mismo script bash desde la línea de comandos funciona.

¿Alguna idea de por qué sucede esto o cómo solucionarlo?

actualizar

Resulta que estaba equivocado, y la clave ssh estaba protegida con contraseña (con el llavero cargando el agente ssh), de ahí por qué falló en un script pero no cuando se ejecutaba desde la sesión bash. Agregar . ~/.keychain/$HOSTNAME-sha mi script resolvió el problema (gracias a @grawity que me señaló en la dirección correcta y proporcionó una respuesta integral).

Los comandos interactivos y los trabajos cron se ejecutan en diferentes entornos, en particular, una sesión interactiva puede tener un agente SSH ejecutándose o un Kerberos TGT almacenado. Debido a la forma en que sshordena los métodos de autenticación, no puede estar seguro de que su clave se use solo porque agregó la -iopción.

• Si se está ejecutando un agente SSH, el sshcliente siempre prueba las claves del agente antes de usar cualquier clave especificada explícitamente.

• Si la red usa Kerberos y hay un TGT de Kerberos, OpenSSH lo usará antes de intentar la autenticación de clave pública.

No sé nada sobre su entorno, pero ambas posibilidades son fáciles de verificar:

1. Agregue unset SSH_AUTH_SOCKy unset KRB5CCNAMEantes del sshcomando, luego ejecute manualmente el script modificado.

   Esto evitará que el script vea al agente o los tickets de Kerberos, y solo usará la clave especificada explícitamente.

2. Agregue la -vopción a ssh. Esto mostrará más detalles sobre cómo ocurre la autenticación.

También puede agregar -oIdentitiesOnly=yesal sshcomando; esto lo obligará a usar la clave especificada .

Y si agrega sugerencias para acceder al agente desde cron, aún mejor

Esto generalmente no se recomienda, ya que el agente generalmente está estrechamente vinculado a su sesión de inicio de sesión interactiva. En particular, solo comienza cuando inicias sesión y desaparece cuando cierras sesión, y necesita tu contraseña para desbloquear las claves SSH (suponiendo que estén protegidas con contraseña).

Usted mencionó "Llavero". ¿Es este el programa OS X o el script Linux? (No sé mucho sobre la arquitectura de Mac OS X, pero AFAIK hace que sea mucho más difícil acceder al agente ssh del usuario desde un cronjob ...)

Otra solución a este problema es configurar cron en ssh en el cuadro local para ejecutar el comando ssh en lugar de ejecutar el archivo o comando por su ruta local absoluta. Esto almacena en caché el KRB5CCNAME y funciona donde / path / command no lo hace.

# 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

Puede usar ssh-cron para configurar conexiones SSH programadas para proteger servidores sin exponer sus claves SSH, pero usando el agente SSH.

puedes ejecutar tu script o comando en crontab como:

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

o

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