crontab + ssh-agent/ssh-add

Bonjour,

je dipose de plusieurs machines toutes linux.

je souhaite mettre en place un système de sauvegarde automatisé des
données de toutes ces machines sur un seul serveur de sauvegarde (lui
même sauvegardé sur une autre machine).

Pour faire mes sauvegardes, j'utilise un compte utilisateur dont une clé
publique DSA est distribuée sur les machines distantes. Lorsque je me
loggue sur le compte de sauvegarde un petit ssh-agent suivi d'un ssh-add
de la clé privée me permet d'exécuter mes script de sauvegarde sans
problème.

Mon souci est le suivant : je souhaite automatiser ces tâches et donc
les planifier dans le crontab. Lorsque je le fais mes programmes de
backup ne parviennent pas à se connecter sur les machines sur lesquelle
ils récupèrent les données sans problème normalement.
Ma question : comment faire pour que les programmes lancés par la
crontab bénéficient des accès normalement offerts par le ssh-add?

La solution de compromis est de ne point mettre de passphrase à tes
clés. Par contre, pour ces clés, à usage exclusif, tu les cantonneras à
leur seule fonction au travers des options du fichier
~.ssh/authorized_keys2 (ou défini par la directive AuthorizedKeysFile du
fichier /etc/ssh/sshd_config, ainsi:

command="/path/to/bin/script_de_sauvegarde",no-agent-forwarding,no-port-forwarding
...<clé>... surcouf@debianfr.net

Pour plus de renseignements:
http://www.oreilly.com/catalog/sshtdg/chapter/ch08.html#13075

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net

Bonsoir,

On Mon, 17 Jan 2005, Lionel wrote:

Pour faire mes sauvegardes, j'utilise un compte utilisateur dont une clé
publique DSA est distribuée sur les machines distantes. Lorsque je me
loggue sur le compte de sauvegarde un petit ssh-agent suivi d'un ssh-add
de la clé privée me permet d'exécuter mes script de sauvegarde sans
problème.

Mon souci est le suivant : je souhaite automatiser ces tâches et donc
les planifier dans le crontab. Lorsque je le fais mes programmes de
backup ne parviennent pas à se connecter sur les machines sur lesquelle
ils récupèrent les données sans problème normalement.
Ma question : comment faire pour que les programmes lancés par la
crontab bénéficient des accès normalement offerts par le ssh-add?

Tu as eu la solution de Raphaël, qui personnellement me pose problème,
parce que ta clé privée non chiffrée sera sauvegardée, donc plus protégée
du tout. Et même si elle n'est pas sauvegardée, quelqu'un récupère ton
disque dur, et hop'...

J'utilise une autre solution, voici un extrait de code que j'ai dans mon
.bashrc/.zshrc:

-----
SSHAGENT=`ps aux | grep ssh-agent | grep -v grep | grep eabalea | wc -l`
if [ $SSHAGENT -gt 0 ]; then
# echo -n "ssh-agent found... "
. tmp/ssh-agent.env > /dev/null
else
echo "ssh-agent not found, starting it."
ssh-agent > tmp/ssh-agent.env
. tmp/ssh-agent.env
echo "Adding main identities to ssh-agent"
ssh-add .ssh/id_rsa .ssh/id_dsa .ssh/....
fi
unset SSHAGENT
-----

Ce script est valable tel quel pour un utilisateur classique, interactif.
Pour une machine, il faudrait remplacer la deuxième clause (le else), pour
envoyer des injures à l'administrateur.

Tu corriges ce qui m'est personnel, et ça devrait marcher.

Si quelqu'un d'autre que toi est root sur ta machine, alors il peut
utiliser ton agent. Mais il pouvait déjà le faire avant, donc....

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
J'y connait rien en usenet, je sais pas comment on fait pour
supprimer tout les newsgroups
-+- FM in GNU : Pour tout casser, ya un howto ? -+-

Bonsoir,

On Mon, 17 Jan 2005, Lionel wrote:

Pour faire mes sauvegardes, j'utilise un compte utilisateur dont une clé
publique DSA est distribuée sur les machines distantes. Lorsque je me
loggue sur le compte de sauvegarde un petit ssh-agent suivi d'un ssh-add
de la clé privée me permet d'exécuter mes script de sauvegarde sans
problème.

Mon souci est le suivant : je souhaite automatiser ces tâches et donc
les planifier dans le crontab. Lorsque je le fais mes programmes de
backup ne parviennent pas à se connecter sur les machines sur lesquelle
ils récupèrent les données sans problème normalement.
Ma question : comment faire pour que les programmes lancés par la
crontab bénéficient des accès normalement offerts par le ssh-add?

Tu as eu la solution de Raphaël, qui personnellement me pose problème,
parce que ta clé privée non chiffrée sera sauvegardée, donc plus protégée
du tout. Et même si elle n'est pas sauvegardée, quelqu'un récupère ton
disque dur, et hop'...

Encore faudrait-il pouvoir récupérer le disque dur en question... En
outre, ma solution préconise de limiter énormément les accès de cet
utilisateur, notamment par l'option command.

J'utilise une autre solution, voici un extrait de code que j'ai dans mon
.bashrc/.zshrc:

-----
SSHAGENT=`ps aux | grep ssh-agent | grep -v grep | grep eabalea | wc -l`
if [ $SSHAGENT -gt 0 ]; then
# echo -n "ssh-agent found... "
. tmp/ssh-agent.env > /dev/null
else
echo "ssh-agent not found, starting it."
ssh-agent > tmp/ssh-agent.env
. tmp/ssh-agent.env
echo "Adding main identities to ssh-agent"
ssh-add .ssh/id_rsa .ssh/id_dsa .ssh/....
fi
unset SSHAGENT
-----

Ce script est valable tel quel pour un utilisateur classique, interactif.
Pour une machine, il faudrait remplacer la deuxième clause (le else), pour
envoyer des injures à l'administrateur.

Ce qui sous-entend de s'identifier au moins une fois avec le clé privée
auprès de l'agent, soit. Cela étant dit, ton script est encore
perfectible: en effet, j'espère que tu n'écris pas dans /tmp/ sans quoi,
le nom de ton fichier est par trop prévisible et peut-être remplacé par
une personne mal intentionnée.

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net

Bonsoir,

On Mon, 17 Jan 2005, Lionel wrote:

Pour faire mes sauvegardes, j'utilise un compte utilisateur dont une clé
publique DSA est distribuée sur les machines distantes. Lorsque je me
loggue sur le compte de sauvegarde un petit ssh-agent suivi d'un ssh-add
de la clé privée me permet d'exécuter mes script de sauvegarde sans
problème.

Mon souci est le suivant : je souhaite automatiser ces tâches et donc
les planifier dans le crontab. Lorsque je le fais mes programmes de
backup ne parviennent pas à se connecter sur les machines sur lesquelle
ils récupèrent les données sans problème normalement.
Ma question : comment faire pour que les programmes lancés par la
crontab bénéficient des accès normalement offerts par le ssh-add?

Tu as eu la solution de Raphaël, qui personnellement me pose problème,
parce que ta clé privée non chiffrée sera sauvegardée, donc plus protégée
du tout. Et même si elle n'est pas sauvegardée, quelqu'un récupère ton
disque dur, et hop'...
J'ai testé la solution de Raphaël (merci Raphaël au passage), mais elle

pose un second problème : je ne peux associer qu'une seule commande à
une clé, ce qui n'est pas très pratique. Donc j'écarte cette solution.

J'utilise une autre solution, voici un extrait de code que j'ai dans mon
.bashrc/.zshrc:

-----
SSHAGENT=`ps aux | grep ssh-agent | grep -v grep | grep eabalea | wc -l`
if [ $SSHAGENT -gt 0 ]; then
# echo -n "ssh-agent found... "
. tmp/ssh-agent.env > /dev/null
else
echo "ssh-agent not found, starting it."
ssh-agent > tmp/ssh-agent.env
. tmp/ssh-agent.env
echo "Adding main identities to ssh-agent"
ssh-add .ssh/id_rsa .ssh/id_dsa .ssh/....
fi
unset SSHAGENT
-----

Ce script est valable tel quel pour un utilisateur classique, interactif.
Pour une machine, il faudrait remplacer la deuxième clause (le else), pour
envoyer des injures à l'administrateur.

Tu corriges ce qui m'est personnel, et ça devrait marcher.

Si quelqu'un d'autre que toi est root sur ta machine, alors il peut
utiliser ton agent. Mais il pouvait déjà le faire avant, donc....

En fait j'utilise déjà ce genre de script. et mes backups fonctionnent

parfaitement lorsque je les exécute à la mano. Mais mon problème c'est
que l'agent soit utilisé lorsque la crontab exécute les script de
sauvegarde, et sauf erreur de ma part, crontab ne charge pas le .bashrc,
et s'il le faisait il faudrait quand même lui fournir la passphrase.

Existe-t-il une solution?

Lionel

Tu as eu la solution de Raphaël, qui personnellement me pose problème,
parce que ta clé privée non chiffrée sera sauvegardée, donc plus protégée
du tout. Et même si elle n'est pas sauvegardée, quelqu'un récupère ton
disque dur, et hop'...

Encore faudrait-il pouvoir récupérer le disque dur en question... En
C'est vrai, c'est peu probable mais c'est toujours possible

outre, ma solution préconise de limiter énormément les accès de cet
utilisateur, notamment par l'option command.

oui, et dailleurs je trouve ça excellent comme principe, mais trop

"borné" pour mes besoins.

Lionel.

Bonsoir,

On Mon, 17 Jan 2005, Lionel wrote:

Pour faire mes sauvegardes, j'utilise un compte utilisateur dont une clé
publique DSA est distribuée sur les machines distantes. Lorsque je me
loggue sur le compte de sauvegarde un petit ssh-agent suivi d'un ssh-add
de la clé privée me permet d'exécuter mes script de sauvegarde sans
problème.

Mon souci est le suivant : je souhaite automatiser ces tâches et donc
les planifier dans le crontab. Lorsque je le fais mes programmes de
backup ne parviennent pas à se connecter sur les machines sur lesquelle
ils récupèrent les données sans problème normalement.
Ma question : comment faire pour que les programmes lancés par la
crontab bénéficient des accès normalement offerts par le ssh-add?

Tu as eu la solution de Raphaël, qui personnellement me pose problème,
parce que ta clé privée non chiffrée sera sauvegardée, donc plus protégée
du tout. Et même si elle n'est pas sauvegardée, quelqu'un récupère ton
disque dur, et hop'...

J'ai testé la solution de Raphaël (merci Raphaël au passage), mais elle
pose un second problème : je ne peux associer qu'une seule commande à
une clé, ce qui n'est pas très pratique. Donc j'écarte cette solution.

La commande en question peut aussi bien être un script, hein.

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net

On Tue, 18 Jan 2005, Raphaël 'SurcouF' Bordet wrote:

Tu as eu la solution de Raphaël, qui personnellement me pose problème,
parce que ta clé privée non chiffrée sera sauvegardée, donc plus protégée
du tout. Et même si elle n'est pas sauvegardée, quelqu'un récupère ton
disque dur, et hop'...

Encore faudrait-il pouvoir récupérer le disque dur en question... En

Le disque dur, ou une des bandes de sauvegarde.

outre, ma solution préconise de limiter énormément les accès de cet
utilisateur, notamment par l'option command.

Oui, c'est un avantage. Je compense personnellement par des limitations
côté serveur.

J'utilise une autre solution, voici un extrait de code que j'ai dans mon
.bashrc/.zshrc:

-----
SSHAGENT=`ps aux | grep ssh-agent | grep -v grep | grep eabalea | wc -l`
if [ $SSHAGENT -gt 0 ]; then
# echo -n "ssh-agent found... "
. tmp/ssh-agent.env > /dev/null
else
echo "ssh-agent not found, starting it."
ssh-agent > tmp/ssh-agent.env
. tmp/ssh-agent.env
echo "Adding main identities to ssh-agent"
ssh-add .ssh/id_rsa .ssh/id_dsa .ssh/....
fi
unset SSHAGENT
-----

Ce script est valable tel quel pour un utilisateur classique, interactif.
Pour une machine, il faudrait remplacer la deuxième clause (le else), pour
envoyer des injures à l'administrateur.

Ce qui sous-entend de s'identifier au moins une fois avec le clé privée
auprès de l'agent, soit.

Oui, comme on le fait pour un serveur web en SSL par exemple. Soit tu mets
le mot de passe en clair quelque part, soit tu fais une clé non chiffrée,
soit tu t'assures qu'un admin sera là au reboot. C'est un compromis.

Cela étant dit, ton script est encore
perfectible: en effet, j'espère que tu n'écris pas dans /tmp/ sans quoi,
le nom de ton fichier est par trop prévisible et peut-être remplacé par
une personne mal intentionnée.

Je n'écris pas dans "/tmp/", mais dans "tmp/". Oui, j'aime bien avoir mon
"tmp/" à moi... ;)

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
TM> C'est cense representer quoi les ^W^W^" ?
Ca représente toute l'étendue de l'incommensurable incapacité à
comprendre Usenet de certains neuneus.
-+- MLG in Guide du Neuneu d'Usenet : Usenet 1 - Neuneu 0 -+-

On Tue, 18 Jan 2005, Lionel wrote:

En fait j'utilise déjà ce genre de script. et mes backups fonctionnent
parfaitement lorsque je les exécute à la mano. Mais mon problème c'est
que l'agent soit utilisé lorsque la crontab exécute les script de
sauvegarde, et sauf erreur de ma part, crontab ne charge pas le .bashrc,
et s'il le faisait il faudrait quand même lui fournir la passphrase.

Je ne comprend pas. Tu peux faire exécuter ce que tu veux à ton script,
non? Donc y compris le bout de code fourni. Et si tu l'as lancé au moins
une fois depuis le dernier reboot, tu ne devrais plus avoir besoin de la
passphrase (c'est l'intérêt du script).

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Usenet: lisez bourré, postez déchirés.
-+- LC in <http://neuneu.mine.nu> : Le postage sans peine. -+-

Bonsoir,

On Mon, 17 Jan 2005, Lionel wrote:

Pour faire mes sauvegardes, j'utilise un compte utilisateur dont une
clé
publique DSA est distribuée sur les machines distantes. Lorsque je me
loggue sur le compte de sauvegarde un petit ssh-agent suivi d'un
ssh-add
de la clé privée me permet d'exécuter mes script de sauvegarde sans
problème.

Mon souci est le suivant : je souhaite automatiser ces tâches et donc
les planifier dans le crontab. Lorsque je le fais mes programmes de
backup ne parviennent pas à se connecter sur les machines sur lesquelle
ils récupèrent les données sans problème normalement.
Ma question : comment faire pour que les programmes lancés par la
crontab bénéficient des accès normalement offerts par le ssh-add?

Tu as eu la solution de Raphaël, qui personnellement me pose problème,
parce que ta clé privée non chiffrée sera sauvegardée, donc plus
protégée
du tout. Et même si elle n'est pas sauvegardée, quelqu'un récupère ton
disque dur, et hop'...

J'ai testé la solution de Raphaël (merci Raphaël au passage), mais
elle pose un second problème : je ne peux associer qu'une seule
commande à une clé, ce qui n'est pas très pratique. Donc j'écarte
cette solution.

La commande en question peut aussi bien être un script, hein.
oui, mais au niveau gestion des sauvegarde, ça me force à modifier

le-dit script à chaque fois que je veux ajouter ou modifier une
sauvegarde. Je préfère centraliser ces modifications côté serveur.

On Tue, 18 Jan 2005, Lionel wrote:

En fait j'utilise déjà ce genre de script. et mes backups fonctionnent
parfaitement lorsque je les exécute à la mano. Mais mon problème c'est
que l'agent soit utilisé lorsque la crontab exécute les script de
sauvegarde, et sauf erreur de ma part, crontab ne charge pas le .bashrc,
et s'il le faisait il faudrait quand même lui fournir la passphrase.

Je ne comprend pas. Tu peux faire exécuter ce que tu veux à ton script,
non? Donc y compris le bout de code fourni. Et si tu l'as lancé au moins
une fois depuis le dernier reboot, tu ne devrais plus avoir besoin de la
passphrase (c'est l'intérêt du script).

oui et c'est bien le cas. mais lorsque je plannifie l'exécution du

script depuis la crontab, le script ne parvient pas à se connecter à la
machine distante. C'est comme si les script exécutés depuis la crontab
ne bénéfiçiait pas de l'action du ssh-agent/ssh-add.

en résumé :
script lancé à la mano => OK
même script lancé par le cron => KO