Putty refuses to connect to unknown host with "The server's host key is not cached in the registry"

I figured out the issue: The "The server's host key is not cached in the registry" error is a plink.exe error. Plink.exe must be run previously, so as to add the key to PuTTy's cache:

> plink -v <email address hidden> ls
Looking up host "example.com"
Connecting to 10.10.10.10 port 22
Server version: SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3.3
We claim version: SSH-2.0-PuTTY_Release_0.60
Using SSH protocol version 2
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange with hash SHA-1
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 06:e2:36:2b:17:7f:88:29:59:92:bd:e4:1d:15:28:24
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) y

I'm glad you worked it out, I'll turn this into a faq.

So, actually, this may be partly a putty issue, but I'm not convinced it's reasonable to make the user run plink first manually. Can't we get it to prompt like openssh does, ie asking on the first time you connect to the host then storing that result.

Bug 238869 also mentions this happening when connecting to Launchpad.

It looks like <http://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter2.html> Putty will prompt to accept the key when run interactively, but it's not doing it here. So the bzr bug is that we're invoking it in such a way that it can't do this. I'm not sure if that's because we're providing perhaps a --batch option, or because when it's run as a subprocess it simply can't ask the user.

We do in fact pass "-batch" to putty, maybe we should not.

Maybe someone affected by this bug could try removing that option from bzrlib/transport/ssh.py and see if it fixes it?

Sorry Stas, I typed the wrong user name.

Alexander, can you confirm this fix?

On Thu, 2009-06-11 at 23:37 +0000, Martin Pool wrote:
>
>
>
> So, actually, this may be partly a putty issue, but I'm not convinced
> it's reasonable to make the user run plink first manually. Can't we
> get
> it to prompt like openssh does, ie asking on the first time you
> connect
> to the host then storing that result.

IIRC the API to get the terminal securely [when not started with it] was
only added in Vista or perhaps XP. So putty being a subprocess is
possibly/likely the cause.

-Rob

putty is unable to get access to the terminal, so while it would prompt, the user would be unable to actually type their password/etc.

So we decided that just failing was better than hanging waiting on user input that it could never get (hence -batch).

I don't know about secure terminal access. I can say that openssh has done just fine-by-me for quite some time, at prompting for my password under cygwin. (I haven't tested much in plain cmd.exe)

I always just figured it was a simple limitation of putty.

I've personally switched away and am now using Pageant + Paramiko for almost all my connections, and I think Mark Hammond was probably right about it being the most sane default. plink.exe just isn't very good as a subprocess...

Martin, bzr can't work properly with plink without -batch. So it won't be a fix, it will be regression.
-batch fixed following problem.

This flag was added because when plink encounter new site it does know about yet, plink asking the user not directly via terminal API (as ssh does), but instead uses stdout. And this breaks bzr because bzr tries to use this prompt as real answer for the remote server.
There is no sane way to workaround this. User should manually connect first time to the server with `plink user@host`, allow adding server credentials to internal database of putty/plink. And only after this manual step, bzr can use plink.

Many people have problem with setup plink+bzr. I'm always recommend to use paramiko only. And this always works.

I guess in the past I've forced paramiko to be default, and using plink only if it's configured in BZR_SSH env variable. May be someone revert this change. I'd say it's wrong. paramiko should be default to avoid all tis dance with server key (paramiko simply add new key and go on).

This question really should be in the FAQ or better in the doc.

Vote to mark it Won't Fix.

So, as Alexander says, we apparently cannot fix this in putty, and we should just be getting people to use paramiko unless they really really want plink.