Bonjour,
 
j'ai un script qui permet de faire une sauvegarde à distance via ssh.
Ce script est effectué par l'utilisateur backup, dont la connexion sur le serveur distant en ssh ne nécessite pas de mdp.
 
Lancé à la main, le script s'effectue donc correctement.
Il fait un rsync de mon dossier en local dans un dossier distant puis renvoi le résultat de ma commande dans un fichier de log.
 
Cependant, renseigné dans la crontab, le log me renvoi "Permission denied (Publickey)".
 
En comparant "à la main", je me suis loggé en tant qu'utilisateur backup sans charger l'environnement complet :
sudo su backup (et non sudo su - backup)
et il me renvoit la même erreur, forcément ne chargeant pas l'envirronement, il ne charge pas la clé ssh connue et ne peut pas se logger sur le serveur distant.
 
J'en conclu (peut-être un peu vite) que crontab fait la même erreur, il n'effectue pas le script avec l'environnement complet de backup.
 
Comment indiquer à crontab d'effectuer le script véritablement comme utilisateur backup ?
 
Je vous remercie.
 
M.

salut,
 
ssh a une option pour informer la commande où trouver les clés.

ça crosspost vénère ici http://forum.ubuntu-fr.org/viewtop [...] #p10614201

I don't always ask for something, but when I do...

Sinon c'est résolu ou tu veux plus de détails.
 
SSH c'est mon dada

Et bien comme sur l'autre page :
http://forum.ubuntu-fr.org/viewtop [...] #p10616851
Je me demande si j'ai bien compris le principe de rsync en daemon.
Car le fait d'indiquer à ssh l'emplacement des clés ne résout pas le pb.

Ta crontab, c'est bien celle de l'utilisateur backup ? Je me demande si c'est pas parce que un autre utilisateur (genre root) exécute ta commande ?
 
Le format d'une clé publique (ce que tu trouves dans ~/.ssh/id_[dr]sa.pub et ~/.ssh/authorized_keys sur l'hôte distant) est le suivant : chaine_représentant_la_valeur_de_la_clé user@host
 
Et vu que la clé est propre à l'utilisateur, ça sort une erreur si c'est pas le bon utilisateur qui se connecte. Ou plutôt si sa clé publique n'est pas dans le authorized_keys de l'hôte distant.
Tu peux voir si c'est ça le problème en refaisant la manip pour avoir un couple de clés priv/pub sur ton compte root, et en copiant la nouvelle clé publique vers l'hôte distant (ssh-copy-id je crois).
 
Si maintenant ça fonctionne, tu sais que ta crontab est pas celle de backup ; pour que ça aille mieux, ce que tu peux faire c'est remplacer "script.sh" par "sudo -u backup script.sh" dans crontab.
Si ça fonctionne pas... retire la clé du root local dans le authorized_keys de l'hôte distant
 
En fait... plutôt que de faire le couple de clé, rajoutes juste "sudo -u backup" dans crontab, et test. C'est plus rapide ._.
 
Mais ptèt que j'ai faux sur toute la ligne  

Tu as bien saisi et c'est bien un problème d’environnement à mon avis.
 
Tu n'as que 2 solutions.
La première c'est de passer via un crontab root et de lancer un script qui fera un su - backup ...
Comme tu aurais pu le deviner toi même vu que tu fais la remarque
C'est le moyen de contournement le plus utilisé généralement.
Pas forcément le plus propre mais certainement le plus simple.
 
Une méthode plus "propre" serait de lancer un ssh-agent avec la bonne clef.
Et ensuite d'utiliser cet agent pour chacune des connexion.

En fait je manipule crontab connecté en tant que backup
$ sudo su - backup
connecté en tant que backup
$ crontab -e
Dans ce cas il me semble que c'est bien la crontab de backup qui est éditée.
 
Et il n'est pas question de faire un backup avec root, car je suis en environnement professionnel et il est interdit par l'entreprise d'effectuer des manipulations usuelles avec root.
 
Je précise que mon script fonctionne hors crontab, à la main il n'y a aucun soucis.
Il me semble que le problème est bien celui indiqué par sputnik, que ssh ne fonctionne pas correctement avec crontab.
 
J'ai testé le rsync en mode daemon, ça fonctionne sans ssh, mais je suis obligé de passer par ssh pour que les données ne circulent pas en clair, et le problème reste présent.
Ou alors je n'ai pas bien renseigné la commande rsync cliente avec ssh.

De mémoire c'est quelque chose comme :

Pour utiliser le ssh. Par défaut rsync n'utilise pas le ssh. Et oui le rsync en mode daemon, c'est pas tip top pour la sécurité, je préfères aussi amplement le passage via SSH.

En tout cas une chose est sure, le ssh est tout a fait utilisable dans un script lancé par la cron, j'en ai des dizaines en production

Pour moi ton problème est bien lié a l'environnement. Si j'en juges par ton post de départ :

Pour que ce soit le cas, tu dois utiliser une des méthodes ci-dessous :
- utilisation d'un .shosts
  --> Devrait fonctionner tout pareil via la cron
- pas de passphrase sur ta clé privée
  --> Devrait fonctionner tout pareil via la cron
- tu utilises un agent ssh
  --> Il te faut impérativement exporter les variables SSH_AGENT_PID et SSH_AUTH_SOCK pour que ton script puisse utiliser l'agent (settées bien sur avec le retour que tu as eu lors de la commande ssh-agent)

Attention quand même au client ssh qui est utilisé par défaut : Assures toi que tu utilises bien le même client ssh quand tu es en interactif que quand tu es en mode cron. Il n'est pas rare que l'OS soit installé avec un client ssh par défaut, et qu'un autre client soit installé en plus sur le serveur (souvent OpenSSH), les deux ayant des config par défaut différentes. Par exemple le nom par défaut des clés peu très bien être différents, ce qui fait qu'il ne trouverait pas la clé privée et donc qu'il plante lors de la connexion.

EDIT : éventuellement ajoute le compte cible dans la connexion SSH. dans el cas du sudo su backup par exemple, ca ne m'étonnerait pas que le compte cible testé par le ssh soit le compte avec lequel tu es connecté sur le serveur et non backup. Chez moi par exemple :

Lors de mon login sur backup :
moi@client$ sudo su - backup
[sudo] password for moi:  
 
KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL
 
 * Found existing ssh-agent (1300)
 * Found existing gpg-agent (1326)
 * Known ssh key: /home/backup/.ssh/id_rsa
 
[backup@client ~]$  
 
La clé de l'utilisateur backup, protégée par mot de passe, mais sans passphrase était déjà existante (créée par l'admin précédent). Je n'ai fait que l'exporter.
backup@client$ ssh-copy-id -i ~/.ssh/id_rsa.pub utilisateur2@serveur
 
Il en résulte que lorsque je me connecte :
backup@client$ ssh utilisateur2@serveur
Last login: date hour from domain.com
utilisateur2@serveur:~$  
je suis connecté sans avoir à entrer de passphrase.
 
Mon script, qui n'est globalement qu'un rsync, lorsqu'il est lancé à la main fonctionne.
backup@client$ /chemin/script.sh
Ok. Backup Succeed.
Contenu du script en gros :
rsync --force --ignore-errors --delete --delete-excluded --backup -arhv /chemin/ utilisateur2@serveur:/chemin/ > /chemin/logfile.log 2>&1
D'ailleurs par la suite j'ai renseigné uniquement cette commande dans crontab.
 
Sachant que mon serveur de backup est aussi celui qui héberge le serveur VPN, j'ai renseigné d'abord l'IP publique (le serveur est accessible depuis le net) dans la commande (@serveur) et ajouté l'option -e ssh, puis j'ai essayé avec son IP d'interface VPN sans l'option -e ssh, ça fonctionne dans les 2 cas hors crontab mais pas dans crontab.
 
Enfin, j'ai remarqué qu'une commande rsync de backup dans crontab était déjà présente.
m h d m d rsync -aHvz --delete-after serverfichier2(VPN):/chemin/ /chemin/
 
Du coup je me suis dit je vais faire pareil, j'ai installé une crontab sur le seveur de backup
m h d m d rsync -aHvz --delete-after serverfichier1(VPN):/chemin/ /chemin/
Mais j'imagine que je dois avoir une clé ssh.
 
Quand tu dis "Il te faut impérativement exporter les variables SSH_AGENT_PID et SSH_AUTH_SOCK", c'est en plus de la commande ssh-copy-id ?

euh,
en local, tu exportes les clés vers le serveur. ça, c'est fait.
en local, tu configures cron pour l'utilisateur, afin d'exécuter rsync avec ssh (en indiquant éventuellement le chemin des clés).
 
ça devrait fonctionner comme ça.

En gros, vous lui proposez de faire de la merde : des clefs sans passphrase alors que la solution daemon rsync est LA solution.

alors répond à ses inquiétudes, pour qu'il arrête de faire les choses à l'envers, et fasse quelque chose de sécurisé, proprement.

J'ai déjà répondu aux questions, après si c'est moi qui l'installe et le configure, je peux linker mon Paypal©®™