plink's host key is not cached in the registry when run from perl on IIS/Windows

Question

I'm trying to start a perl script on another server from a web page and I'm having problems with plink: it doesn't seem to remember the host key when run from the IUSR_ user.

I managed to reduce the problem this:

print "Content-Type:text/plain\n\n";
open(PLINK, "| \"C:\\Program Files\\PuTTY\\plink.exe\" -pw sanitized Administrator\@serveurftp.a.b.c whoami") or die "Can't fork: $!";
sleep(1);
print PLINK "y\n";
close(PLINK);

When calling this script from a web page, I always get this:

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 cb:eb:dc:1b:9e:1c:6b:fa:63:fb:2e:ba:2c:61:26:c4
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) serveurftp\administrator

I should only be getting this on the first time, and only "serveurftp\administrator" afterwards, but it looks like plink can't store the host key when it's run from IIS.

Do you guys have any idea on how to work around this?

Answer 1

In a case like this, an application will often try to read the y/n response from the console (or in Unix speak, tty) and not necessarily from standard input, so the program is probably not registering the "y" response that you pipe to it.

Some workarounds might be:

1. Run the command as the IIS user from the command-line. Maybe that will persist the host for the call from the webserver.
2. Run the command from the command-line as yourself. Find your user's cache file and copy the key from that file into the administrator's cache file.
3. If your webserver program has a console window on your machine, try accessing this script from a browser and then typing "y" into that console window when the script reaches the point where it is prompting you for this response (this probably won't work because the program might already be running in a child process, but it might be worth a try)