Selon Patrice KARATCHENTZEFF <patrice.karatchentzeff-alplog@???>:
> > A moins que ce soit plus compliqué, du genre un
> > scp user1@B:source user2@C:dest
> > (ce qui nécessite l'usage de l'Agent Forwarding pour distribuer les clefs
> > privés - ce qui expliquerait le tunnel)
>
> oui, c'est cela... la copie est faite par une machine tierce qui établit
> la connexion entre les deux machines.
OK j'ai bien deviné. C'était la seule façon d'avoir un tunnel avec scp.
Heureusement que j'ai le bouquin SSH d'Oreilly sous le coude ;)
Donc ton problème implique trois machines:
. A: client qui lance un scp entre B et C
. B: serveur ssh que A contacte - avec connection cliente scp vers C
. C: serveur ssh que B contacte
B est configuré pour l'agent forwarding
A contient les clefs publique/privée
B et C contiennent la clef publique
Question subsidiaire: il est où le firewall ? entre A et B ou B et C ?
Est-ce que tu as trouvé des logs suspects ? Genre "connection reset by peer".
Est-ce que tu peux ajouter l'option '-v' à scp au cas où
un indice apparaîtrait ?
Si c'est la connection A->B qui pose problème, pourquoi ne pas planifier la
commande directement sur la machine B ?
Est-ce qu'il y a du traffic entre A et B lors de la copie ? Si non, cela
peut expliquer que le firewall coupe.
Sinon, une autre façon est que A lance une commande
'at [..] scp B:source C:dest > scp.log' sur B par ssh puis coupe sa connection.
A condition bien sur de fournir une paire de clefs à l'utilisateur sur B...
A ce propos, scp ne sait pas copier les fichiers spéciaux ni les liens
symboliques. Dans ce cas, il faut ruser avec une sorte de
"tar cf - source | ssh user@C tar xf -"
Le livre d'Oreilly parle de deux paramètres en plus des KeepAlive,
ClientAlive*:
- IdleTimeout sur le serveur et idle-timeout sur le client
Mais visiblement ces options ne sont plus présentes...
Si tu trouves la cause et une solution, je suis très curieux de la connaître.
A+
--
Yves Martin
