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 /dev/tty.

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.


Writing to /dev/tty does not take the process-id into account; you will not succeed in that way.

Although it is the same device, there are different file-descriptors which a process will have open on a given device. For Linux, you can manipulate the separate file-descriptors if you know the process-id, i.e., /proc/PID/fd/0 is the standard input for the process whose id is PID.

For your case, the program is opening the device, and its file-descriptor would also be in /proc/PID/fd (but not as well identified). An application could "see" the symlink information from within that directory, and manipulate it.

If you look closely, the items in /proc/PID/fd all have different inode values (because they are different file descriptors). Echoing to the entry in proc/PID/fd means you are echoing to that file descriptor.

But ssh is not expecting input from that direction, has no provision for supplementary prompts - a workaround such as you are using is probably the best you'll be able to do.

| improve this answer | |
  • 1
    I'm not sure what workaround you think I'm using. I don't think I presented one. Can you elaborate? Also, with ls -li I can get the inode numbers. What can I do with them? Can I use that to write to where I want things to go? If so, how? – Jonas Kölker Oct 11 '16 at 12:35
  • It seemed you had: unwedge the stuck scp by identifying the file descriptor which it is using for input by giving it the information it wants. I mentioned inodes to demonstrate that although these point to the same device (the scrp process's /dev/tty), they are distinct (because they're separate file descriptors). – Thomas Dickey Oct 11 '16 at 23:34
  • 1
    Nope, I did not unstuck it, because I didn't work out how to feed ssh input, nor did I find out that this is impossible. – Jonas Kölker Oct 12 '16 at 9:25

I avoided this problem when working with embedded systems that were frequently reinstalled (thus generating new host keys). If you want to blindly accept the new host key, you can do so, but be aware that this removes any defence against impersonation of the other side. It may be appropriate for low-risk actions on a well-controlled network, but is not recommended for use on the public Internet!

For the hosts in question, make ssh write auto-accept the new host key, but write it to /dev/null:

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no

There doesn't seem to be an option for SSH to never check known_hosts.

If the problem in the question is that the host keys were never known to this client (as opposed to known but now changed), then it should be sufficient to add -o StrictHostKeyChecking=no to the SSH command line.

To reiterate, only do this if you accept the reduction in security. I'm assuming you do, as you say you want to unconditionally respond yes to interactive SSH.

| improve this answer | |
  • This doesn't really answer the question. Evidently Jonas knows how host key checking works, and is trying to rescure this one already-running command. – Gilles 'SO- stop being evil' Oct 11 '16 at 23:25
  • 1
    It's nice to have UserKnownHostsFile and StrictHostKeyChecking pointed out to me. In this particular application, I want host key checking, though. I can edit the caller of ssh to call it from the timeout program myself. The part I don't know, as @Gilles pointed out, is how to get the system unstuck by feeding input to ssh. I got the system-as-a-whole unstuck by killing this particular ssh, but I would still like to know if I could have also fed in input. – Jonas Kölker Oct 12 '16 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.