Process running in SSH-allocated TTY not terminating once stdin is consumed

1

1

I can perform file-transfer via SSH* like this:

ssh -T ${HOST} eval "cat > remote.txt" < local.txt

However, if I instead allocate a TTY, it hangs until I press Ctrl+C:

ssh -tt ${HOST} eval "cat > remote.txt" < local.txt

Question: Why is this? Is there a workaround?

The best I can figure out is that the local EOF is not being propagated to the remote process.

Platform details: OpenSSH_5.3p1, CentOS 6.7 x86_64


* In my real use-case, I want to use this approach to transfer files directly to a remote sudo user; I can't use SCP because I can't SSH as the sudo user. The sudoers file in my target environment has requiretty set, hence the need for a TTY.

Oliver Charlesworth

Posted 2015-12-20T19:20:15.307

Reputation: 972

why the eval? It is not needed, isn't it? – Jakuje – 2015-12-20T20:14:46.780

@Jakuje: echo "hello" | ssh -T ${HOST} "cat > foo.txt" leads to cat: >: No such file or directory. And you can't remove the quotes, because then that redirection occurs locally! – Oliver Charlesworth – 2015-12-20T20:25:59.967

@Jakuje: On further inspection, that appears to be a difference in SSH clients (the above issue is observed with OpenSSH 6.2 on OSX, but not 5.3 on Linux). – Oliver Charlesworth – 2015-12-20T20:32:12.707

Are you trying on the same server? This might be problem with different shells on server. But, yes, using exec makes sure it works almost everywhere. The tty allocation is evergreen problem since 2001, aka bug #52 in openssh, still not completely solved.

– Jakuje – 2015-12-20T20:38:09.807

@Jakuje - It's not immediately obvious that this is the same issue. The description there involves the child process (sleep) not receiving a SIGHUP at the "correct" time; in my case the child cat process is never terminating, presumably because its stdin is never exhausted. – Oliver Charlesworth – 2015-12-20T21:17:02.057

No answers