ssh-agent y crontab - ¿Existe una buena manera de conseguir éstos para satisfacer?
Pregunta
Escribí un guión simple que envía por correo a cabo los registros de actividad SVN todas las noches para nuestros desarrolladores. Hasta ahora, he ejecutarlo en la misma máquina que el repositorio SVN, por lo que no tiene que preocuparse acerca de la autenticación, que sólo podía usar el archivo de SVN:. /// estilo de dirección
Ahora estoy ejecutando la secuencia de comandos en un ordenador personal, para acceder a un repositorio remoto, así que tuve que cambiar a svn + ssh: // caminos. Con ssh-clave bien hecha, no siempre tienen que introducir contraseñas para acceder al repositorio SVN en circunstancias normales.
Sin embargo, crontab no tenía acceso a mi llaves ssh / ssh-agent. He leído acerca de este problema un par de lugares en la web, y también es aludido aquí, sin resolución:
Por qué falla ssh de crontab pero succedes cuando se ejecuta desde una línea de comandos?
Mi solución fue la de añadir esto a la parte superior de la secuencia de comandos:
### TOTAL HACK TO MAKE SSH-KEYS WORK ###
eval `ssh-agent -s`
Esto parece funcionar bajo MacOSX 10.6.
Mi pregunta es, qué terrible es esto, y hay una manera mejor?
Solución
Al ejecutar ssh-agent -s, se inicia un proceso de fondo que necesitará para matar más tarde. Por lo tanto, el mínimo es cambiar su truco para algo como:
eval `ssh-agent -s`
svn stuff
kill $SSH_AGENT_PID
Sin embargo, no entiendo cómo este truco está trabajando. Simplemente ejecutando un agente sin correr también ssh-add no se carga ninguna tecla. Tal vez MacOS' ssh-agente se comporta de manera diferente que su página manual dice que lo hace.
Otros consejos
Además ...
Si la clave tiene un passhphrase, llavero le pedirá que una vez (válido hasta que se reinicie la máquina o matar al ssh-agent).
llavero es lo que necesita! Sólo tiene que instalar y añadir el código de seguimiento en su .bash_profile:
keychain ~/.ssh/id_dsa
Así que usar el siguiente código en el script para cargar las variables de entorno ssh-agent:
. ~/.keychain/$HOSTNAME-sh
Nota: llavero también genera código para CSH y peces conchas
.He tenido un problema similar. Mi script (que se basó en las claves SSH) trabajó cuando me encontré de forma manual, pero fracasó cuando se ejecuta con crontab.
definir manualmente la tecla adecuada con
ssh -i /path/to/key
no funcionó.
Pero con el tiempo descubrí que la SSH_AUTH_SOCK estaba vacía cuando el crontab estaba corriendo SSH. No estaba muy segura de por qué, pero me
env | grep SSH
copiado el valor devuelto y ha añadido esta definición a la cabeza de mi crontab.
SSH_AUTH_SOCK="/tmp/value-you-get-from-above-command"
Estoy fuera de profundidad en cuanto a lo que está pasando aquí, pero fijo mi problema. El crontab funciona sin problemas ahora.
Una manera de recuperar el PID y el zócalo de ejecutar ssh-agent sería.
SSH_AGENT_PID=`pgrep -U $USER ssh-agent`
for PID in $SSH_AGENT_PID; do
let "FPID = $PID - 1"
FILE=`find /tmp -path "*ssh*" -type s -iname "agent.$FPID"`
export SSH_AGENT_PID="$PID"
export SSH_AUTH_SOCK="$FILE"
done
Por supuesto, esto supone que ha instalado pgrep en el sistema y solo hay un ssh-agent en ejecución o en el caso de los múltiples que tomará el que se encuentra pgrep pasado.
Mi solución - sobre la base de la ARP - mejoró ligeramente a matar el proceso, incluso en caso de fallo de script:
eval `ssh-agent`
function cleanup {
/bin/kill $SSH_AGENT_PID
}
trap cleanup EXIT
ssh-add
svn-stuff
Tenga en cuenta que debo llamar a ssh-add en mi máquina (Scientific Linux 6).
Si se asume que ya ha configurado la configuración de SSH y que la escritura funciona bien desde el terminal, utilizando la llavero es, sin duda la forma más fácil de asegurarse de que la escritura funciona bien en el crontab también.
Desde llavero no está incluido en la mayoría de las derivaciones de Unix / Linux, aquí está el procedimiento paso a paso.
1 Descargar el paquete rpm correcto dependiendo de la versión del sistema operativo desde http:. / /pkgs.repoforge.org/keychain/ . Ejemplo para CentOS 6:
wget http://pkgs.repoforge.org/keychain/keychain-2.7.0-1.el6.rf.noarch.rpm
2 Instala el paquete:.
sudo rpm -Uvh keychain-2.7.0-1.el6.rf.noarch.rpm
3. Generar archivos de llavero para su clave SSH, que estarán ubicados en el directorio ~ / .keychain. Ejemplo para id_rsa:
keychain ~/.ssh/id_rsa
4 Añadir la siguiente línea a su script en cualquier lugar antes de que el primer comando que usa la autenticación SSH:.
source ~/.keychain/$HOSTNAME-sh
Yo personalmente trató de evitar el uso de programas adicionales para esto, pero todo lo demás que probamos no funcionó. Y esto funcionó muy bien.
Para configurar procesos automatizados sin hacks contraseña / frase de contraseña automatizados,
Yo uso un IdentityFile independiente que no tiene ninguna frase de contraseña, y restringir las entradas de los equipos de destino authorized_keys el prefijo from="automated.machine.com" ...
etc ..
He creado un conjunto de claves pública-privada para la máquina de envío sin una frase de contraseña:
ssh-keygen -f .ssh/id_localAuto
(Hit retorno cuando se le solicite para una frase de contraseña)
He creado una entrada en remoteAuto anfitrión .ssh/config
:
Host remoteAuto
HostName remote.machine.edu
IdentityFile ~/.ssh/id_localAuto
y los remote.machine.edu:.ssh/authorized_keys con:
...
from="192.168.1.777" ssh-rsa ABCDEFGabcdefg....
...
A continuación, ssh no necesita la autorización autentificado externamente proporcionada por ssh-agente o llavero, para que pueda utilizar comandos como:
scp -p remoteAuto:watchdog ./watchdog_remote
rsync -Ca remoteAuto/stuff/* remote_mirror
svn svn+ssh://remoteAuto/path
svn update
...
Inspirado por algunas de las otras respuestas aquí (en particular de VPK) se me ocurrió la siguiente entrada en el crontab, que no requiere un script externo:
PATH=/usr/bin:/bin:/usr/sbin:/sbin
* * * * * SSH_AUTH_SOCK=$(lsof -a -p $(pgrep ssh-agent) -U -F n | sed -n 's/^n//p') ssh hostname remote-command-here
Aquí es una solución que funcione si no se puede utilizar llavero y si no se puede iniciar un ssh-agente de la secuencia de comandos (por ejemplo, debido a que su clave es la frase de contraseña-protegida).
Ejecutar esta vez:
nohup ssh-agent > .ssh-agent-file &
. ssh-agent-file
ssh-add # you'd enter your passphrase here
En el script se ejecuta desde cron:
# start of script
. ${HOME}/.ssh-agent-file
# now your key is available
Por supuesto, esto permite a cualquiera que pueda leer '~ / .ssh-agent-archivo' y el enchufe correspondiente a usar sus credenciales de ssh, a fin de utilizar con precaución en cualquier entorno multi-usuario.
Sus trabajos solución, pero generará un nuevo proceso de agente cada vez que como ya se ha indicado por alguna otra respuesta.
Me enfrenté a problemas similares y me encontré con este entrada de blog útil, así como la secuencia de comandos shell por Wayne Walker mencionado en el blog en github .
Buena suerte!