Heldwin a écrit 4 commentaires

Hello

J'ai réussi, mais je dois encore faire des tests dessus.

Sur CentOS:

Dans ~/.bash_profile :
*********************
eval `ssh-agent -s`
ssh-add < /dev/null
ssh-add ~/.ssh/id_rsa < /dev/null
echo "SSH_AGENT_PID=$SSH_AGENT_PID" > ~/.ssh-agent
echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK" >> ~/.ssh-agent
echo "export SSH_AGENT_PID SSH_AUTH_SOCK" >> ~/.ssh-agent
*********************

Dans le script cron:
*********************
. ~/.ssh-agent
*********************

Je dois regarder car cela me laisse plusieurs "ssh-agent -s" avec des pid différents dans ps -aux. Je pense tuer tuer le PID par ~/.bash_logout.

Ok merci :)

Je pensais qu'il y avait une histoire de variables à mettre, mais pas eu trop le temps de regarder ca.

J'essayerais d'insérer ces variables d'environnement demain matin. J'utilise une RHEL 4 migré en CentOS 4.5.

Si ca ne marche pas chez moi non plus, vais bien trouver un moyen de le faire :) Et posterais au cas où je trouve une solution.

En tout cas, je te remercie pour ton aide.

Ah ok :) Merci

Pourtant ca marchait avant, puis maintenant je recois des messages: Permission denied (Public Key). Depuis une mise à jour serveur il me semble.

Il n'y a pas un moyen de garder la pass phrase et d'utiliser cron ? ou de lancer crontab comme fils de ssh-agent ?

Je voulais aussi rajouter que le même script utilisé pour faire le backup localement fonctionne avec crontab.

Ce n'est que lors de backup distant qu'il plante.

Peut-être qu'il faut que je fasse passer une variable à crontab ?

le script utilise #!/bin/sh, et la commande:

rsync -av -e ssh repertoire root@domaine:/destination

De root à root, avec juste une clé publique qui fonctionne si je lance le script sans crontab.

Si vous avez besoin de plus d'infos, je traine par là :)
Merci