Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 10/02/2015, à 16:03

Linuxman[13]

[RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Bonjour,
j'essaie d'automatiser une tâche grâce à CRON, voici ma ligne dans le crontab :
*/1  *  *   *   *     scp -i /home/pedro/.ssh/id_rsa.pub pedro@192.168.11.89:/home/pedro/Pierre/ssh/pq.txt /home/pedro/Bureau/Pierre/pq.txt 2> /var/log/cron.log

Je veux récupérer, toutes les minutes, le fichier "pq.txt" sur un serveur distant.
J'ai au préalable fait un échange de clé publique entre les deux ordinateurs et activé le ssh agent, afin de ne pas avoir à entrer de mot de passe lors de la connexion.
Lorsque j'exécute la commande "scp" depuis le prompt de l'utilisateur root, le fichier est correctement récupéré sur le serveur distant, en revanche lorsque je passe par le CRONTAB de l'utilisateur root, cela ne se passe pas comme prévue et le fichier "auth.log" du serveur distant me retourne les lignes suivantes :

Feb 10 15:51:01 localhost sshd[9557]: Failed password for pedro from 192.168.11.63 port 45874 ssh2
Feb 10 15:51:01 localhost sshd[9557]: Failed password for pedro from 192.168.11.63 port 45874 ssh2
Feb 10 15:51:01 localhost sshd[9557]: Connection closed by 192.168.11.63 [preauth]

Je ne comprends pas et suis complètement pommé .. ! Merci d'avance pour votre aide !

Dernière modification par Linuxman[13] (Le 16/02/2015, à 10:45)

Hors ligne

#2 Le 10/02/2015, à 16:27

gl38

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Pourquoi passer par root ?
La clé est sans doute stockée chez toi pas dans le dossier perso de root.
Ensuite je ne suis pas sûr que le programme lancé par crontab sache vraiment qui tu es et il va falloir lui expliquer.
Cordialement,
Guy

Hors ligne

#3 Le 10/02/2015, à 17:05

claudius01

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

gl38 a écrit :

... Ensuite je ne suis pas sûr que le programme lancé par crontab sache vraiment qui tu es et il va falloir lui expliquer.

Pas tout à fait d'accord, si le piège du crontab est qu'il fonctionne avec un environnement pratiquement vide, les variables d'environnement HOME, LOGNAME et SHELL sont tout de même positionnées et pouvant être vérifiés par (echo $HOME $LOGNAME $SHELL) dans un script qui engloberait l'appel à scp.

gl38 a écrit :

Pourquoi passer par root ?

Là, entièrement d'accord ;-)

Maintenant, cf. crontab execution doesn't have the same environment variables as executing user car il est bien possible de "resourcer" le profile du LOGNAME (toujours dans un script qui engloberait l'appel à scp) suffise à corriger le problème.

Dernière modification par claudius01 (Le 10/02/2015, à 17:24)

Hors ligne

#4 Le 10/02/2015, à 21:59

gl38

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

@claudius01 : tu as raison, ça marche tout seul avec un cron lancé par l'utilisateur qui a fait l'échange des clés.
Cordialement,
Guy

Hors ligne

#5 Le 11/02/2015, à 09:04

Linuxman[13]

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

La clé est stockée dans le dossier de root puisque j'ai fait l'échange de clé depuis cette utilisateur (je l'ai aussi fait depuis l'utilisateur non administrateur "pedro"). J'ai décider d'utiliser cet utilisateur afin de ne pas avoir de problème de droits lors de l'exécution des différentes commandes au travers de cron.
Vous ne trouvez pas bizarre que la commande "scp" fonctionne lorsque je l'exécute directement depuis le prompt, et pas lorsque je la lance au travers de cron ?

Hors ligne

#6 Le 11/02/2015, à 09:36

Linuxman[13]

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Je ne comprends pas très bien ce qui est dit dans le lien que tu as envoyé Claudius01..
Cron, par défaut, ne possède pas toutes les informations qui lui permettent d'exécuter le "scp" ?

Hors ligne

#7 Le 11/02/2015, à 10:02

gl38

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Ce qui est étonnant c'est que ta commande puisse marcher ! Il me semble que l'option -i n'est pas faite pour ça et il n'y a pas besoin d'options du tout après l'échange des clés. Il faut aussi voir que les clés contiennent le nom de l'utilisateur et que les clés de root et de pedro ne sont pas interchangeables.
Cordialement,
Guy

Hors ligne

#8 Le 11/02/2015, à 10:56

claudius01

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Linuxman 13 a écrit :

Cron, par défaut, ne possède pas toutes les informations qui lui permettent d'exécuter le "scp" ?

Je dirais non, mais peux-tu ajouter l'option -v dans la ligne de commande de scp dans le cas qui fonctionne et depuis l'appel par cron (on en saura plus en comparant les 2 cas ;-)
cf. bash: using scp in cron job fails, but runs succesfully when run from command line qui ressemble à ton problème.

As-tu essayé comme gl38 depuis un compte normal et qui est affirmatif :
"@claudius01 : tu as raison, ça marche tout seul avec un cron lancé par l'utilisateur qui a fait l'échange des clés."

Hors ligne

#9 Le 11/02/2015, à 14:01

Linuxman[13]

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Voilà ce que la commande scp m'a renvoyé lorsque je l'exécute depuis le prompt de mon utilisateur "pedro" :

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.11.89 [192.168.11.89] port 22.
debug1: Connection established.
debug1: identity file /home/pedro/.ssh/id_rsa type 1
debug1: identity file /home/pedro/.ssh/id_rsa-cert type -1
debug1: identity file /home/pedro/.ssh/id_dsa type -1
debug1: identity file /home/pedro/.ssh/id_dsa-cert type -1
debug1: identity file /home/pedro/.ssh/id_ecdsa type -1
debug1: identity file /home/pedro/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pedro/.ssh/id_ed25519 type -1
debug1: identity file /home/pedro/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-8
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 1f:b8:71:67:a8:9a:22:d7:42:30:fb:13:8a:6f:a8:7b
debug1: Host '192.168.11.89' is known and matches the ECDSA host key.
debug1: Found key in /home/pedro/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/pedro/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.11.89 ([192.168.11.89]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending command: scp -v -f /home/pedro/Pierre/ssh/pq.txt
Sending file modes: C0644 518 pq.txt
Sink: C0644 518 pq.txt
pq.txt                                        100%  518     0.5KB/s   00:00    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 3444, received 3168 bytes, in 0.0 seconds
Bytes per second: sent 78191.1, received 71924.9
debug1: Exit status 0

Voici le résultat lorsque j'exécute la commande depuis le crontab de l'utilisateur pedro :

Executing: program /usr/bin/ssh host 192.168.11.89, user pedro, command scp -v -f /home/pedro/Pierre/ssh/pq.txt
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.11.89 [192.168.11.89] port 22.
debug1: Connection established.
debug1: identity file /home/pedro/.ssh/id_rsa type 1
debug1: identity file /home/pedro/.ssh/id_rsa-cert type -1
debug1: identity file /home/pedro/.ssh/id_dsa type -1
debug1: identity file /home/pedro/.ssh/id_dsa-cert type -1
debug1: identity file /home/pedro/.ssh/id_ecdsa type -1
debug1: identity file /home/pedro/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pedro/.ssh/id_ed25519 type -1
debug1: identity file /home/pedro/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-8
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 1f:b8:71:67:a8:9a:22:d7:42:30:fb:13:8a:6f:a8:7b
debug1: Host '192.168.11.89' is known and matches the ECDSA host key.
debug1: Found key in /home/pedro/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/pedro/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_parse_private2: missing begin marker
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Trying private key: /home/pedro/.ssh/id_dsa
debug1: Trying private key: /home/pedro/.ssh/id_ecdsa
debug1: Trying private key: /home/pedro/.ssh/id_ed25519
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Dernière modification par Linuxman[13] (Le 11/02/2015, à 14:37)

Hors ligne

#10 Le 11/02/2015, à 14:16

gl38

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Utilise les balises <> bleues juste au-dessus de la case de composition du message pour envelopper les résultats de commande.
Cordialement,
Guy

Hors ligne

#11 Le 11/02/2015, à 15:11

Linuxman[13]

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Je penses que lors de l'exécution de la commande via crontab, il cherche la pass-phrase pour m'authentifier avec la machine distante, mais il ne la trouve pas, il essaye plusieurs fois, en vain, alors il change sa méthode d'authentification et passe en authentification par mot de passe et au final me renvoie :
"Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password)."
(j'ai bien activer l'SSH-agent afin que la machine mémorise la pass-phrase) Qu'en dites-vous ?

Hors ligne

#12 Le 11/02/2015, à 15:26

claudius01

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Effectivement, en comparant les 2 résultats, il apparait ces messages dans le cas d'un lancement par cron qui pourraient intéresser un spécialiste du réseau :

...
debug1: key_parse_private2: missing begin marker
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Trying private key: /home/pedro/.ssh/id_dsa
debug1: Trying private key: /home/pedro/.ssh/id_ecdsa
debug1: Trying private key: /home/pedro/.ssh/id_ed25519
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
...

Manifestement, il y a un repliement sur la méthode password car  "Next authentication method: password" au lieu de "Next authentication method: publickey" dans le cas qui fonctionne...

Une suggestion tout de même: Refaire un essai (si cela n'a pas été déjà fait) en "ressourçant" le "profile" du compte 'pedro' avant l'appel à scp comme déjà abordé à mon post #3.

Dernière modification par claudius01 (Le 11/02/2015, à 15:27)

Hors ligne

#13 Le 11/02/2015, à 15:38

Linuxman[13]

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Merci pour la suggestion,mais je ne sais pas comment procéder ..
Que dois-je indiquer dans le script qui contient la commande scp ?

Hors ligne

#14 Le 11/02/2015, à 16:01

claudius01

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Tu gardes la commande scp telle quelle, tu crées un  script '/home/pedro/scp.sh' qui l’appellera comme par exemple (je suppose qu'il y a un fichier .profile sous '/home/pedro' :

#!/bin/bash
env > /tmp/envBeforeProfile.txt
. /home/pedro/.profile
env > /tmp/envAfterProfile.txt
scp -v ...
exit $?

Nouveau crontab avec mise en commentaire du lancement de scp et appel au script :

#*/1  *  *   *   *     scp -i /home/pedro/.ssh/id_rsa.pub pedro@192.168.11.89:/home/pedro/Pierre/ssh/pq.txt /home/pedro/Bureau/Pierre/pq.txt 2> /var/log/cron.log
*/1  *  *   *   *     /home/pedro/scp.sh

Le but est de ressourcer le profile du compte et connaître l'environnement avant et après...

Dernière modification par claudius01 (Le 11/02/2015, à 16:03)

Hors ligne

#15 Le 16/02/2015, à 09:42

Linuxman[13]

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Merci pour l'aide ! J'ai réaliser le script que tu m'a donné puis l'ai exécuter, mais les fichier envBeforeProfile et envAfterProfile sont exactement les même ! Alors soit j'ai fait une erreur lors de l'écriture du ressourcement du profile (c'est bien à ça que sert la ligne numéro 3 du script?), soit ça signifie que l'environnement de l'utilisateur "pedro", dans Cron, est bien complet ?

Hors ligne

#16 Le 16/02/2015, à 10:37

Linuxman[13]

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Ok je viens de tomber sur un post similaire au miens sur un forum anglais, le gars aurait résolu son problème en mettant une passphrase vide au moment de la création de la clé. J'ai fait de même et effectivement ça fonctionne. En revanche ce n'est pas très sécurisé. Mais il me semble que la passphrase sert simplement à protéger l'accès à la clé privé n'est-ce pas ? Autrement dit, si l'accès à l'ordinateur qui détient la passphrase est bien sécurisé, pas de problèmes ?

Je rappelle que, lorsque j'avais essayer le scp avec une passphrase, j'avais aussi activer l'agent ssh, donc pas besoin de la saisir lors de la première connexion dans la session courante.. Je vais mettre ça en résolu, merci beaucoup pour votre aide tout de même (dédicace à Claudius qui est présent sur tous mes problèmes, lol)

Dernière modification par Linuxman[13] (Le 16/02/2015, à 10:44)

Hors ligne

#17 Le 20/02/2015, à 09:06

tiramiseb

Re : [RESOLU] Commande "scp" via CRON qui retourne un "failed password"

Salut,

En effet, on ne peut pas automatiser avec une clé ayant une phrase de passe. Désolé de n'avoir pas pu répondre plus tôt, j'aurais pu te l'indiquer dès le début, c'est assez commun comme erreur hmm

L'agent SSH n'est utilisable que par les logiciels de la même session, pas par des trucs lancés dans une autre session (donc pas par des trucs lancés par cron).

il me semble que la passphrase sert simplement à protéger l'accès à la clé privé n'est-ce pas ? Autrement dit, si l'accès à l'ordinateur qui détient la passphrase est bien sécurisé, pas de problèmes ?

Oui, en gros si tu as le moindre doute quant à un éventuel piratage de l'ordinateur où il y a la clé privée, il faut vite vite supprimer la clé publique du serveur concerné.

Hors ligne