☰

ssh Permiso denegado sólo en el trabajo cron

tag-icon • tag-icon bash ssh cron
ssh Permiso denegado sólo en el trabajo cron

Teniendo 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 autenticación de clave pública).

Cuando ejecuto este script manualmente desde la línea de comando, funciona bien, pero cuando lo coloco en /etc/cron.hourly falla y genera un Permission denied, please try again.error.

  • Configuré explícitamente la clave en el script usando ssh -i /root/.ssh/id_rsa user@remote "command";
  • el script se ejecuta como root (agregué un echo `id` > /tmp/whoami.logpara verificarlo); 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 me equivoqué y la clave ssheraprotegido con contraseña (con el llavero cargando el agente ssh), de ahí que falló desde un script pero no cuando se ejecutó desde la sesión de bash. Agregar . ~/.keychain/$HOSTNAME-sha mi script resolvió el problema (gracias a @grawity que me indicó la dirección correcta y me brindó una respuesta completa).

Respuesta1

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 TGT Kerberos almacenado.Debido a la forma en que sshordena los métodos de autenticación, ustedno puedoasegúrese 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 agenteantesutilizando cualquier clave especificada explícitamente.

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

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

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

    Esto evitará que el script vea el agente o los tickets de Kerberos y solo utilizará 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 puedes agregar -oIdentitiesOnly=yesal sshcomando; esta voluntadforzarlo a usar la clave especificada.

Y si agrega consejos sobre cómo acceder al agente desde cron, aún mejor

Por lo general, esto no se recomienda, ya que el agente suele estar estrechamente vinculado a su sesión de inicio de sesión interactiva. En particular, solo se inicia cuando inicias sesión y se cierra cuando cierras la sesión, y necesita tu contraseña para desbloquear las claves SSH (suponiendo que estuvieran protegidas con contraseña).

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

Respuesta2

Otra solución a este problema es configurar cron en ssh en el cuadro local para, a su vez, 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

Respuesta3

Puedes usarssh-cronpara configurar conexiones SSH programadas para proteger servidores sin exponer sus claves SSH, pero usando el agente SSH.

Respuesta4

puedes ejecutar tu script o comando en crontab como:

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

o

0 * * * * bash -c -l "ssh root@tuhost 'echo $NOMBREHOST'"

información relacionada