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é
requiretty
dé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!
exec
garantit 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 SIGHUP
au moment "correct"; dans mon cas, le cat
processus 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?