#1 Le 07/07/2006, à 01:05
- Julian
ssh + clés ssh + crontab = serveur distant qui refuse la connection
Hello,
J'ai un serveur dédié que j'administre à distance via ssh.
Pour plus de sécu et de confort, j'utilise uniquement une connexion ssh par clé publique et clé privée, ssh-add est lancé, je n'ai donc plus à rentrer de mot de passe pour toute la session et ça permet la création de script ssh automatisé. Tout ça fonctionne à merveille. Voilà pour la présentation du bordel.
Je suis en train de mettre en place une stratégie de Backup (sites du serveur) avec une tâche cron qui s'exécute sur mon pc de bureau.
Le script qui s'éxecute à cette tête là, on va l'appeler "backup.cmd" :
#!/bin/sh
DATE=$(date +%d-%m-%Y-%H-%M)
mkdir /home/julian/Backup/Site/${DATE}
ssh user@monserveur.org mysqldump -u utilisateur -pmotdepasse nom_base_de_donnee > /home/julian/Backup/Site/${DATE}/nom_base_de_donnee${DATE}.sql
scp -r user@monserveur.org:/var/www/site_web/* /home/julian/Backup/Site/${DATE}/
Bref grâce à ça je transfert d'un seul coup, tout le contenu du site web ainsi que la base sql appropriée.
Executé seul en console donc:
sh backup.cmd
Ca marche parfaitement et mon but est d'automatiser tout ça.
Executé dans une tâche cron de ce type avec mon propre user (celui qui a les autorisations par clés ssh):
*/45 * * * * sh /home/julian/Backup/backup_Score.cmd > /home/julian/Backup/log/error.log
Là le dossier se créé comme prévu mais il n'y a que la base sql qui s'enregistre
Rien à faire avec la commande scp, le transfert des documents ne démarre pas.
Le fichier de log me dit:
permission denied key....
En gros j'ai l'impression que le crontab ne me permet pas de m'identifier avec mes clés ssh pour la commande scp.
Désolé c'est long mais comme c'est un problème assez précis.
Si vous avez une idée, j'imagine que je ne dois pas être le seul à vouloir automatiser des tâches à distances via ssh et scp.
Merci pour vos réponses
@+
Julian.
Dernière modification par Julian (Le 07/07/2006, à 05:22)
julian@jabber.fr
Hors ligne
#2 Le 07/07/2006, à 11:41
- Uggy
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
Il y aurait pas à mettre dans le script les valeurs de SSH_AGENT_PID et SSH_AUTH_SOCK ?
printenv | grep "^SSH_A"
Hors ligne
#3 Le 08/07/2006, à 15:14
- Julian
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
Non toujours rien
julian@jabber.fr
Hors ligne
#4 Le 08/07/2006, à 15:58
- Uggy
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
-Qu'est ce que tu as ajouté exactement au script?
-Est ce que le message d'erreur est différent ?
- Est ce que tu as fait une recherche sur Goggle avec les éléments aoutours de ces 2 variables ?
Hors ligne
#5 Le 08/07/2006, à 16:34
- Julian
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
Salut,
Ben j'ai mis ça en +:
SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.XXX; export SSH_AUTH_SOCK;
SSH_AGENT_PID=XXXX; export SSH_AGENT_PID;
Correspondant évidemment à mon propre "ssh-agent".
Ben là le problème c'est qu'en rajoutant ce bout de code, ça demande mon mot de passe lors de l'utilisation manuelle du script, c'est donc pas la peine d'aller plus loin dans cron.
En enlevant ce bout de code, ça fonctionne sans mot de passe grâce à "ssh-add".
Mais j'avoue ne pas bien maitrisé cette histoire de SSH_AUTH_SOCK.... c'est pas faute de chercher, mais je sais pas, j'ai du mal avec ça .
Dernière modification par Julian (Le 08/07/2006, à 16:38)
julian@jabber.fr
Hors ligne
#6 Le 08/07/2006, à 16:54
- lgmdmdlsr
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
Bonjour.
En admettant que la solution avec SSH_AUTH_SOCK et SSH_AGENT_PID soit trouvée, il va y avoir un souci majeur : dès la fermeture de la session utilisateur, ssh_agent va être fermé. D'où impossibilité par la suite de s'authentifier.
Personnellement je fais ce genre de copie avec une seconde clef, avec passphrase vide (le chemin vers la seconde clef est indiqué avec l'option -i de scp).
--
lgmdmdlsr
Hors ligne
#7 Le 08/07/2006, à 17:08
- Julian
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
Bonjour.
En admettant que la solution avec SSH_AUTH_SOCK et SSH_AGENT_PID soit trouvée
Salut,
Non non, je veux bien réessayer mais pour moi ce n'est pas la solution.
Il y a à mon avis uniquement un prob entre scp & cron, puisque ssh & cron ne pose pas de problème.
dès la fermeture de la session utilisateur, ssh_agent va être fermé. D'où impossibilité par la suite de s'authentifier.
Personnellement je fais ce genre de copie avec une seconde clef, avec passphrase vide (le chemin vers la seconde clef est indiqué avec l'option -i de scp).
lgmdmdlsr
En fait, je suis seul sur la machine, je ne ferme donc jamais ma session.
De plus, si je viens à redémarrer (ce qui est très rare) j'ai paramétrer la bécane pour qu'aussitôt j'ai une invite me demandant de rentrer la pass phrase donc ça va de ce côté.
Personnellement je fais ce genre de copie avec une seconde clef, avec passphrase vide (le chemin vers la seconde clef est indiqué avec l'option -i de scp).
lgmdmdlsr
J'ai essayé aussi en mettant -i chemin... dans scp, mais ça ne veut pas non plus
Ca ressemble à quoi chez toi la commande scp?
Est-ce opérationnel via cron?
Merci.
Dernière modification par Julian (Le 08/07/2006, à 17:51)
julian@jabber.fr
Hors ligne
#8 Le 08/07/2006, à 17:30
- lgmdmdlsr
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
Type de commande scp passant avec une crontab:
scp -i /home/lgmdmdlsr/.ssh/id_rsa_2 -r distant@loin.ici:/home/distant/rep /home/lgmdmdlsr/rep2/
avec /home/lgmdmdlsr/.ssh/id_rsa_2 une clef avec passphrase vide.
--
lgmdmdlsr
Hors ligne
#9 Le 09/07/2006, à 01:33
- Uggy
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
Met direct la ligne dans la crontab (au lieu du script)
crontab -l
SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.XXX
*/45 * * * * sh /home/julian/Backup/backup_Score.cmd > /home/julian/Backup/log/error.log
Hors ligne
#10 Le 22/07/2009, à 14:33
- Un bon samaritin
Re : ssh + clés ssh + crontab = serveur distant qui refuse la connection
Merci pour cette réponse ça fonctionne très bien de cette manière!