# Scp via cron

**URL:** <https://www.debian-fr.org/t/scp-via-cron/78709>\
**Category:** Support Debian\
**Created:** [Mars 1, 2019, 7:38 UTC](https://www.debian-fr.org/t/scp-via-cron/78709 "2019-03-01T07:38:08Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![phdb44](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e36b37/32.png) [@phdb44](https://www.debian-fr.org/u/phdb44)\
**Post date:** [Mars 1, 2019, 7:38 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/1 "2019-03-01T07:38:08Z")

</div>

Bonjour,

Le script :

```nohighlight
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` :

```nohighlight
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 :

```nohighlight
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

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 1, 2019, 8:14 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/2 "2019-03-01T08:14:54Z")

</div>

> [@phdb44](#):
>
> Si le script est lancé manuellement

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 «&nbsp;`sign_and_send_pubkey`&nbsp;» m’inspire un truc à tester (intuition).  
Dans ton script, avant ton `scp`, essaye d’ajouter une ligne:  
**`eval "$(ssh-agent)"`**

---

<div class="post-metadata">

**Author:** ![phdb44](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e36b37/32.png) [@phdb44](https://www.debian-fr.org/u/phdb44)\
**Post date:** [Mars 1, 2019, 9:40 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/3 "2019-03-01T09:40:57Z")

</div>

Bonjour, et merci pour cette réponse,

> [@mattotop](#):
>
> 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.

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 çà ?

> [@mattotop](#):
>
> 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)"`**

Ça me renvoie ‹&nbsp;`Agent pid 5033`&nbsp;›

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 1, 2019, 9:48 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/4 "2019-03-01T09:48:55Z")

</div>

> [@phdb44](#):
>
> Donc je dois mettre le script dans le `cron` de `root`

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.

> [@phdb44](#):
>
> Ça me renvoie ‘`Agent pid 5033`’

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 ?

---

<div class="post-metadata">

**Author:** ![phdb44](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e36b37/32.png) [@phdb44](https://www.debian-fr.org/u/phdb44)\
**Post date:** [Mars 1, 2019, 10:02 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/5 "2019-03-01T10:02:33Z")

</div>

> [@mattotop](#):
>
> 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.

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

> [@mattotop](#):
>
> > Ça me renvoie ‘`Agent pid 5033`’
> 
> Ca a changé quelque chose ?

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`).

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 1, 2019, 11:01 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/6 "2019-03-01T11:01:22Z")

</div>

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` ?

---

<div class="post-metadata">

**Author:** ![phdb44](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e36b37/32.png) [@phdb44](https://www.debian-fr.org/u/phdb44)\
**Post date:** [Mars 1, 2019, 11:24 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/7 "2019-03-01T11:24:24Z")

</div>

```nohighlight
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.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 1, 2019, 12:13 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/8 "2019-03-01T12:13:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![phdb44](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e36b37/32.png) [@phdb44](https://www.debian-fr.org/u/phdb44)\
**Post date:** [Mars 1, 2019, 12:22 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/9 "2019-03-01T12:22:45Z")

</div>

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

> [@mattotop](#):
>
> Bizarre, j’ai bien plus verbeux que ça même sans échec, avec des infos sur la discussion `sshd/pam_unix`.

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

```plaintext
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.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 1, 2019, 12:31 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/10 "2019-03-01T12:31:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![phdb44](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e36b37/32.png) [@phdb44](https://www.debian-fr.org/u/phdb44)\
**Post date:** [Mars 1, 2019, 12:50 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/11 "2019-03-01T12:50:08Z")

</div>

> [@mattotop](#):
>
> - 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.

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 :

```plaintext
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`:

```plaintext
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]

```

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 1, 2019, 1:19 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/12 "2019-03-01T13:19:25Z")

</div>

> [@phdb44](#):
>
> 3 autres serveurs

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

> [@phdb44](#):
>
> ```plaintext
> Ligne 97 : input_userauth_pk_ok: fp SHA256:
> Ligne 98 : sign_and_send_pubkey: RSA SHA256:
> 
> ```

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`.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 1, 2019, 1:20 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/13 "2019-03-01T13:20:23Z")

</div>

> [@mattotop](#):
>
> On peut donc présumer que le probléme vient de la config du serveur cible du `scp`

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

---

<div class="post-metadata">

**Author:** ![phdb44](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e36b37/32.png) [@phdb44](https://www.debian-fr.org/u/phdb44)\
**Post date:** [Mars 1, 2019, 1:27 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/14 "2019-03-01T13:27:26Z")

</div>

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

> [@mattotop](#):
>
> 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`.

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.

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Mars 1, 2019, 1:47 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/15 "2019-03-01T13:47:43Z")

</div>

Bonjour

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

```plaintext
ssh-keygen -t rsa -b 4096

```

* * *

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

```plaintext
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 :

```plaintext
* * * * * 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`**

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

```

* * *

**NOTE :**

> [@phdb44](#):
>
> …Dossier `.ssh` en `700` et contenu en `600` .

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

```plaintext
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:~$ 

```

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 1, 2019, 10:04 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/16 "2019-03-01T22:04:25Z")

</div>

> [@anon29980398](#):
>
> tous les fichiers qu’il contient ne sont pas en **`600`**

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

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Mars 2, 2019, 7:42 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/17 "2019-03-02T07:42:33Z")

</div>

```nohighlight
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:~$ 

```

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Mars 2, 2019, 7:59 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/18 "2019-03-02T07:59:23Z")

</div>

Zut, oui, r c’est 4.

> [@mattotop](#):
>
> reste est en **622**

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 @anon29980398 .

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Mars 2, 2019, 9:49 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/19 "2019-03-02T09:49:53Z")

</div>

Dans [l’exemple d’utilisation de la commande **`scp`**](https://www.debian-fr.org/t/scp-via-cron/78709/15) 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 :

```nohighlight
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:~$ 

```

---

<div class="post-metadata">

**Author:** ![phdb44](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e36b37/32.png) [@phdb44](https://www.debian-fr.org/u/phdb44)\
**Post date:** [Mars 3, 2019, 1:49 UTC](https://www.debian-fr.org/t/scp-via-cron/78709/20 "2019-03-03T13:49:38Z")

</div>

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:

- [http://www.linux-france.org/prj/edu/archinet/systeme/ch13s03.html](http://www.linux-france.org/prj/edu/archinet/systeme/ch13s03.html)
- [https://forum.ubuntu-fr.org/viewtopic.php?id=1183671](https://forum.ubuntu-fr.org/viewtopic.php?id=1183671)
- [https://unix.stackexchange.com/questions/304881/how-to-automatically-add-keyfile-and-passphrase-to-ssh-agent?rq=1](https://unix.stackexchange.com/questions/304881/how-to-automatically-add-keyfile-and-passphrase-to-ssh-agent?rq=1)
- [https://www.server-world.info/en/note?os=Debian\_9&p=ssh&f=7](https://www.server-world.info/en/note?os=Debian_9&p=ssh&f=7)
- [https://www.quennec.fr/trucs-astuces/systèmes/gnulinux/utilisation/connexion-à-une-machine-distante-ssh-scp-sftp-sans-saisir-le-mot-de-passe](https://www.quennec.fr/trucs-astuces/syst%C3%A8mes/gnulinux/utilisation/connexion-%C3%A0-une-machine-distante-ssh-scp-sftp-sans-saisir-le-mot-de-passe)
- [https://www.quennec.fr/trucs-astuces/systèmes/gnulinux/commandes/ssh/copier-la-clé-dun-host-dans-le-fichier-authorizedkeys-dun-host-distant](https://www.quennec.fr/trucs-astuces/syst%C3%A8mes/gnulinux/commandes/ssh/copier-la-cl%C3%A9-dun-host-dans-le-fichier-authorizedkeys-dun-host-distant)

Merci encore