Scp via cron

Support Debian
#1

Bonjour,

Le script :

scp /home/pierre/shells/zoli.txt pierre@orion:/public/

Si le script est lancé manuellement, il fonctionne bien.
Si le script est lancé par le cron il plante.

mon environnement :
2 machines sous Stretch
Certificat généré sur chaque machine sur le compte pierre. Clé public copié dans chaque fichier authaurized_keys distant. Dossier .ssh en 700 et contenu en 600.
sshd_config :

  • PermitRootLogin no
  • PasswordAuthentication no
    Cela ne résout rien si je passe les 2 lignes à yes.

Connexion ssh ok dans les 2 sens.

J’ai tenté l’option -i pour forcer le chemin de l’emplacement du certificat – sans succès.
J’ai maintenu l’option -i et j’ai ajouté le mode debug :

scp -vvv -B -i /home/pierre/.ssh/id_rsa /home/pierre/shells/zoli.txt pierre@orion:/public/. >/home/pierre/shells/traces.txt 2>&1

J’ai d’abord lancé le script manuellement, ensuite je l’ai lancé via le cron, puis j’ai comparé les traces :
Les 98 premières lignes sont strictement identiques :

Ligne 97 : input_userauth_pk_ok: fp SHA256:
Ligne 98 : sign_and_send_pubkey: RSA SHA256:

Ligne 99 : lancé manuellement : send packet: type 50
Ligne 99 : lancé par cron : we did not send a packet, disable method
 
Ligne 100 : lancé manuellement : receive packet: type 52
Ligne 100 : lancé par cron : No more authentication methods to try
 
Ligne 101 : lancé manuellement : Authentication succeeded (publickey)
Ligne 101 : lancé par cron : Permission denied (publickey)
 
Ligne 102 : lancé manuellement : Authenticated to orion ([192.168.101.4]:22)
Ligne 102 : lancé par cron : lost connection

Il n’y a pas d’autres lignes dans les traces du script lancé par cron.

Donc, si j’en crois les logs, en passant par cron j’ai un problème d’authentification. J’imagine que c’est un problème de droits ou d’accès lié au process cron qui ne semble pas avoir les mêmes privilèges que l’utilisateur… (ce n’est pas root ?)

Je suis un peu (beaucoup) perdu… Si quelqu’un pouvait m’éclairer, ce serait vraiment sympa.

Merci d’avance

#2

Lancé manuellement en tant que pierre, ou root ?
Si tu l’as testé en tant que pierre, ce n’est pas bon. C’est root qui doit pouvoir se connecter.

Sinon, le message parlant de “sign_and_send_pubkey” m’inspire un truc à tester (intuition).
Dans ton script, avant ton scp, essaye d’ajouter une ligne:
eval "$(ssh-agent)"

#3

Bonjour, et merci pour cette réponse,

Je l’ai testé en tant que Pierre.
Ok.
Donc je dois mettre le script dans le cron de root; et par conséquent générer un certificat root sur chaque machine, recopier la clé public de chacun dans chaque authorized_keys distant et enfin autoriser la connexion de root dans sshd_config.
C’est bien çà ?

Ça me renvoie ‘Agent pid 5033’

#4

Attention, non:
je pensais que tu avais mis ça dans le cron de root, donc dans ce cas, il faut tester le script en tant que root.
Mais si tu executes le cron en tant que pierre (excellente idée), alors c’est cohérent, ce n’est pas là qu’est le probléme.

Oui, c’est normal:
ça lance un agent pour l’échange de clés et c’est le message de retour de l’instruction (qui n’a pour nous aucune importance, sauf si tu as besoin du PID pour killer l’agent aprés).
L’agent qui est nécessaire pour la transaction est en général lancé automatiquement lorsque tu es en session interactive, mais je me disais que lors du cron, il n’y en avait peut être pas de lancé.
Ca a changé quelque chose ?

#5

C’est bien avec le cron de l’utilisateur pierre que je fais le test.

Oui et non
Non, parce que cela ne fonctionne toujours pas via le cron,
Oui, mais pas dans le bon sens, puisque en insérant cette ligne, cette fois-ci le script plante lorsque je le lance manuellement (et dans les traces j’obtiens les mêmes erreurs que le lancement via le cron).

#6

Sur le serveur (là ou tu vas te connecter), pourrais tu extraire de /var/log/auth.log les lignes correspondant à une session compléte d’authentification ssh ratée lors du cron ?

#7 
Mar  1 12:18:01 Orion sshd[13195]: Connection closed by 192.168.101.34 [preauth]
Mar  1 12:21:02 Orion sshd[13271]: Connection closed by 192.168.101.34 [preauth]

2 essais, 2 résultats identiques.
l’IP 34 étant bien la machine qui lance le script.

#8

Bizarre, j’ai bien plus verbeux que ça même sans échec, avec des infos sur la discussion sshd/pam_unix.
Boon, ça ne dit rien…

Un peu sec, là.

Essayes:

  • vérifie le authorizedkeys distant, d’abord pour vérifier que tu ne l’as pas créé comme authorisedkeys (avec un s au lieu du z) et pour voir si en recopiant tu n’as pas fait une typo genre oublier le premier, le dernier caractére, ou un retour à la ligne à la fin
  • essaye de passer les fichiers de ton .ssh client et/ou serveur en 644 (sauf les id_XXX sans .pub, les fichiers de clé privée qui doivent rester en 600).
    Mais dans les 2 cas il me semble que ça poserait problème même en manuel, donc bon.
#9

Merci déjà pour toutes ces réponses.

Voilà le retour en lançant le script manuellement:

Mar  1 13:18:15 Orion sshd[13912]: Accepted publickey for pierre from 192.168.101.34 port 39906 ssh2: RSA 79:79:59:3b:af:17:2e:14:7f:88:85:09:cf:3c:92:34
Mar  1 13:18:15 Orion sshd[13912]: pam_unix(sshd:session): session opened for user pierre by (uid=0)
Mar  1 13:18:15 Orion systemd-logind[792]: New session 809 of user pierre.
Mar  1 13:18:15 Orion sshd[13914]: Received disconnect from 192.168.101.34: 11: disconnected by user
Mar  1 13:18:15 Orion sshd[13912]: pam_unix(sshd:session): session closed for user pierre
Mar  1 13:18:15 Orion systemd-logind[792]: Removed session 809.

Je regarde les autres points et je fais un retour dans la foulée.

#10

Sinon, juste un truc à coté, plutôt que de copier/coller tes clés à la main avec les erreurs possibles,
utilises ssh-copy-id pour les transfèrer proprement.

#11

J’ai vérifié les fichiers authorized_keys. Pas de souci sur la typo. Je ne me souviens plus comment j’ai intégré les certificats (ssh-copy ou manuellement), mais dans la mesure ou ssh fonctionne, je présume que c’est conforme.

J’ai remis à 644 authorized_keys et known_hosts, puis j’ai retenté un lancement par cron: auth est toujours aussi peu loquace :

Mar  1 13:30:01 Orion sshd[14161]: Connection closed by 192.168.101.34 [preauth]

J’ai dupliqué le script et tenté la manip sur 3 autres serveurs (Debian 8.11, 9.7, 9.8).
Même échec et même résultat sur le log auth:

Mar  1 13:40:01 phebus3 sshd[28507]: Connection closed by 192.168.101.34 port 56670 [preauth]
Mar  1 13:41:01 phenix sshd[14841]: Connection closed by 192.168.101.34 port 36546 [preauth]
Mar  1 13:42:02 Aio2 sshd[22145]: Connection closed by 192.168.101.34 port 36178 [preauth]
#12

On peut donc présumer que le probléme vient de la config du serveur cible du scp.

Je vois dans ton premier message sur les différences entre les logs manuel et cron que dans le cas scripté, ça parle de RSA.
Regardes si tu ne peux pas jouer sur des arguments de sshd_config comme AuthenticationMethods, RSAAuthentication, ou essayes de forcer Protocol à 1 ou au contraire à 2 (quitte si ça marche en 1 a trouver pour faire marcher en 2)
Vérifies aussi si PubkeyAuthentication est bien à yes
Tu peux aussi vérifier si tes fichiers ont les bons droits, en mettant StrictModes à no: si ça passe, c’est que c’est un probléme de droits à creuser pour pouvoir remettre l’argument à yes.

#13

Disons que c’est plus probable que la même erreur de config sur tous les serveurs client.

#14

Déjà, merci encore pour l’effort et le temps passé, c’est cool de ta part.

Je regarde tout cela et je te renvoie le retour.

En parallèle je suis en train de terminer la création de 2 VMs sous debian 9.8 (Virtualbox), histoire de ne pas être pollué par l’historique des configs.

#15

Bonjour

Depuis mon compte utilisateur (michel)
j’ai généré une clef RSA sans indiquer de mot de passe,

ssh-keygen -t rsa -b 4096

puis j’ai copié la clef publique vers le compte comptUtilSrv du serveur (192.168.122.80)

ssh-copy-id -i /home/michel/.ssh/id_rsa.pub comptUtilSrv@192.168.122.80

(il m’aura fallu entrer le mot de passe
du compte utilisateur comptUtilSrv sur le serveur 192.168.122.80)

et, depuis mon compte utilisateur,
j’ai créé la ligne crontab suivante :

* * * * * scp -q /home/michel/essai/texte.txt comptUtilSrv@192.168.122.80:/home/comptUtilSrv/

et je constate qu’à chaque minute, le fichier est bien transféré.

L’option -q de scp demande à cette commande de ne pas afficher ses messages
puique dans ce contexte, il lui est impossible d’afficher quoi que ce soit
vu que cron ne lui donne rien pour y connecter ses flux stdout et stderr

On aurait aussi pu
rediriger les flux stdout et stderr vers /dev/null

* * * * * scp /home/michel/essai/texte.txt comptUtilSrv@192.168.122.80:/home/comptUtilSrv/ >/dev/null 2>&1

NOTE :

si mon répertoire ~/.ssh est en 700,
tous les fichiers qu’il contient ne sont pas en 600

michel@debg53sw:~$ ls -l .ssh
total 16
-rw------- 1 michel michel  398 sept. 25 06:50 authorized_keys
-rw------- 1 michel michel 3243 sept. 22 11:42 id_rsa
-rw-r--r-- 1 michel michel  741 sept. 22 11:42 id_rsa.pub
-rw-r--r-- 1 michel michel 1554 mars   1 13:39 known_hosts
michel@debg53sw:~$
#16

C’est ça aussi chez moi.
Les clés privées sont en 600, mais le reste est en 622.

#17 
michel@debg53sw:~$ stat --format='%a %A %n' ~/.ssh/{,*}
700 drwx------ /home/michel/.ssh/
600 -rw------- /home/michel/.ssh/authorized_keys
600 -rw------- /home/michel/.ssh/id_rsa
644 -rw-r--r-- /home/michel/.ssh/id_rsa.pub
644 -rw-r--r-- /home/michel/.ssh/known_hosts
michel@debg53sw:~$
#18

Zut, oui, r c’est 4.

Donc non, en 644
mon autorized_keys aussi est en 644 chez moi, ce qui ne gène pas.
Mais je vais le passer en 600 pour raison de sécurité, merci @MicP .

#19

Dans l’exemple d’utilisation de la commande scp que j’avais décris,
j’avais oublié de préciser que :

dans le fichier /etc/ssh/sshd_config du serveur ssh auquel je me connecte (192.168.122.80)
je n’ai rien modifié, (à part la clause X11Forwarding que j’avais mise à no)

Donc, dans le fichier /etc/ssh/sshd_config du serveur ssh
les seules clauses qui ne sont pas commentées
sont :

comptUtilSrv@debsrvssh:~$ egrep -v "^#|^$" /etc/ssh/sshd_config
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
PrintMotd no
AcceptEnv LANG LC_*
Subsystem	sftp	/usr/lib/openssh/sftp-server
comptUtilSrv@debsrvssh:~$
#20

Alors tout d’abord un grand merci à vous deux pour votre éclairage et vos conseils efficaces.
Je suis donc reparti sur 2 VMs vierges que j’ai triturées à souhait pour essayer de mieux comprendre comment fonctionnaient ssh et ses dérivées, et effectivement je me suis rendu compte qu’il me manquait quelques couches…

Je confirme qu’un scp via le cron fonctionne très bien dès lors que la passphase n’est pas renseignée lors de la génération de la clé.
Au départ, intellectuellement j’avais un peu de mal à accepter l’idée qu’une clé puisse être créée sans passphrase. Mais à la réflexion, il me semble que dès lors que .ssh et son contenu est correctement chmodé, le risque de récupération de la clé est plutôt limité; sachant aussi que le .ssh peut être localisé où on le souhaite…
De plus, j’interdis la connexion root et les connexions ssh sans clés (‘PermitRootLogin no’ & ‘PasswordAuthentication no’ dans sshd_config), ce qui devrait contribuer à limiter les risques.
Et enfin, j’ai appris que l’on pouvait associer une adresse IP/un nom de host à la clé RSA dans le fichier ~/.ssh/authorized_keys (voir dernier lien en fin de page)

J’ai aussi compris qu’une connexion ssh sans demande de passphrase (cette fois-ci renseignée) passait forcément par ssh-agent, mais dont la durée de vie est limitée à la session en cours (je n’ai pas encore trouvé comment réaffecter automatiquement la passphrase lors d’une nouvelle session, mais je suis certain que cela doit être posssible).

Je joins la liste des liens qui m’ont aussi permis d’avancer sur le sujet (çà pourra peut-être servir à d’autres), en plus de vos précieux conseils:

Merci encore

1 J'aime