I have a running system which uses scp(1) to copy files from one host to another. The system is working on a sequence of files, but got stuck on one of them: that is, it started an scp command yesterday which is still running today.
Running strace suggests that scp is waiting to read on a pipe file, which is connected to stdout of its ssh child process; this child is waiting to read on fd 4 which is
One ssh destination had a host key which was in conflict with
known_hosts on the source host. I fiddled with that around the time the long-running scp was started; now the
known_hosts is all set up as it should be, and I can ssh from source to all destinations without being prompted for anything.
My hypothesis is that
ssh hit a small timing window and has presented the user with an unknown host key and is waiting for confirmation (
"yes\n") to go forward.
Is there some way I can make the
read call done by
ssh behave as if the user typed
yes (and if so, how)?
When (on another machine) I
echo foobar > /dev/tty in an xterm, it writes
foobar on my console. The same result happens, unsurprisingly, if I
echo foobar > /proc/<pid>/fd/4 which is a symlink to
/dev/tty. So how do I feed the input into ssh?
If someone knows how to test my hypothesis about
ssh and/or make it proceed in a different way, I'd be happy to hear about that as well.