Je peux effectuer un transfert de fichier via SSH * comme ceci:
ssh -T ${HOST} eval "cat > remote.txt" < local.txt
Cependant, si j'affecte un TTY à la place, il se bloque jusqu'à ce que j'appuie sur Ctrl + C:
ssh -tt ${HOST} eval "cat > remote.txt" < local.txt
Question: Pourquoi est-ce? Y at-il un travail autour?
Le mieux que je puisse comprendre, c'est que l'EOF local n'est pas propagé au processus distant.
Détails de la plateforme: OpenSSH_5.3p1, CentOS 6.7 x86_64
* Dans mon cas d'utilisation réel, je souhaite utiliser cette approche pour transférer des fichiers directement à un utilisateur sudo distant; Je ne peux pas utiliser SCP car je ne peux pas utiliser SSH en tant qu'utilisateur sudo. Le fichier sudoers de mon environnement cible a été
requirettydéfini, d’où la nécessité d’un TTY.
echo "hello" | ssh -T ${HOST} "cat > foo.txt"mène à cat: >: No such file or directory. Et vous ne pouvez pas supprimer les guillemets, car cette redirection se fait localement!
execgarantit que cela fonctionne presque partout. L'allocation de tty est un problème persistant depuis 2001, aussi appelé bogue n ° 52 dans openssh , toujours pas complètement résolu.
sleep) ne reçoit pas a SIGHUPau moment "correct"; dans mon cas, le catprocessus enfant ne se termine jamais, probablement parce que son stdin n'est jamais épuisé.
eval? Ce n'est pas nécessaire, n'est-ce pas?