Acabo de actualizar de Snow Leopard a Lion, y mis trabajos cron que usan ssh han dejado de funcionar. Parece que ssh-agent ya no funciona como se esperaba.
Aquí hay una versión bowdlerizada de mi script llamado desde cron que funcionó muy bien con Snow Leopard:
#!/bin/bash
whoami # just to verify I'm running as myself, not root
ssh-agent # just to see what it outputs
eval `ssh-agent`
ssh -vvv REMOTESERVER ls
Cuando se ejecuta desde el símbolo del sistema, este script funciona como se esperaba.
Cuando se ejecuta desde cron, no funciona. La salida del agente ssh parece normal:
SSH_AUTH_SOCK=/tmp/ssh-QRxPUMRxbu/agent.17147; export SSH_AUTH_SOCK;
SSH_AGENT_PID=17148; export SSH_AGENT_PID;
echo Agent pid 17148;
Agent pid 17150
Pero el ssh -vvv
resultado muestra que falla justo cuando se debe leer la clave privada:
debug1: Server accepts key: pkalg ssh-dss blen 818
debug2: input_userauth_pk_ok: fp ...
debug3: sign_and_send_pubkey: DSA ...
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read_passphrase: can't open /dev/tty: Device not configured
debug2: no passphrase given, try next key
En otras palabras, espera que escriba la frase de contraseña para ~/.ssh/id_dsa
, que por supuesto no funciona en trabajos cron.
Todo esto funcionó en Snow Leopard.
Tenga en cuenta que tengo la configuración de Acceso a Llaves de manera que ssh
, ssh-agent
y ssh-add
se les permite leer mi frase de contraseña para mi .ssh/id_dsa
archivo - como resultado que puedo SSH en un terminal sin tener que entrar en mi contraseña.
¿Es este problema el que necesito ejecutar ssh-add
en algún momento de mi proceso de inicio de sesión? Ejecutarlo desde un indicador de bash estándar no ayuda al trabajo cron (aunque, curiosamente, me solicita mi frase de contraseña ... que creo que no es necesaria b / c de la configuración de Keychain Access).
NOTA 1 - antes de redirigirme - Soy consciente de que hay una pregunta similar aquí (
Mac OS X Lion y sshpass ) pero se trata específicamente de un programa sshpass
que no uso (aunque creo que esa pregunta también sería respondida por esta pregunta) )
NOTA 2 - Me doy cuenta de que las claves SSH sin frase de contraseña resolverían mi problema; Sin embargo, preferiría no seguir esta ruta.
Respuestas:
Para cualquiera que termine en esta página, me di cuenta de que debería publicar la respuesta:
El uso de launchd en lugar de cron sí soluciona el problema de autorización. Los trabajos iniciados por el usuario (que se ejecutan solo cuando está conectado) usan correctamente la información del agente SSH que se desbloqueó a través de su llavero como parte del inicio de sesión (como parte de la administración de claves OS X estándar, no se requiere ningún otro software).
Para minimizar mis interacciones con launchd, creé un solo trabajo de launchd que llama a un script bash. De esta manera, simplemente puedo editar el script sin tener que lidiar con launchd.
Aquí está el archivo launchd:
Guardé el archivo
~/Library/LaunchAgents/com.mycron.hourly.plist
y luego lo cargué con:Una vez cargado, se ejecutará de inmediato y luego nuevamente cada 60 minutos.
Si sigue el mismo procedimiento, querrá cambiar la cadena `ProgramArguments 'con la ruta correcta a su secuencia de comandos.
fuente
Agregar el siguiente código a su script de shell bash solucionará el problema:
Reemplace
your_user
con su propio nombre de usuario.Este código establece el valor correcto para
SSH_AUTH_SOCK
esa informaciónssh
oscp
sobre cómo comunicarsessh-agent
cuando se inicia el script de shellcron
.fuente
zsh: no matches found: /tmp/launch-*/Listeners
Esperaría una seguridad mejorada como sandbox y los cambios para mover aún más las cosas a 64 bits están causando un dolor inesperado.
No es una respuesta, per se, pero launchd está recibiendo todo el amor de Apple en estos días.
No está solucionando el problema de cron, pero es más estable y más personas pueden ayudarlo.
fuente
Para cualquiera que encuentre esto ahora, tratando de hacer que esto funcione en El Capitán, y aún reacio a convertir su trabajo cron de una línea en un script lanzado, la respuesta de Werner Antweiler todavía funciona, pero el camino cambió. Lo siguiente funcionó para mí:
NOTA : ¡recuerde reemplazar your_user con su nombre de usuario!
No me permitió enviar esto como un comentario sobre su respuesta, ya que me falta la reputación, pero no quería dejarla sin actualizar esto, ya que definitivamente me ayudó a configurarlo.
Editar: 30 de marzo de 2016
Después de probar esto por un tiempo, necesito agregar que esto solo funciona una vez que el agente se ha utilizado al menos una vez durante ese inicio de sesión. Iniciar una conexión ssh o ejecutar ssh-agent manualmente es suficiente para hacerlo. Un script de inicio también se puede utilizar si desea que se ejecute automáticamente. Creé un startup.sh que solo ejecuta ssh-agent y luego usé Script Editor para guardar un .app con lo siguiente y agregué la aplicación resultante a mis elementos de inicio de sesión:
fuente
ls /private/tmp/com.apple.launchd.*/Listeners
. No tiene que hacer nada excepto iniciar sesión en mac.