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

[Rolly]

Hello all,

Windows XP user here. Using PuTTy (and plink.exe) version 0.60. I was running an older version of Bzr (1.3 I believe), and all was well. I upgraded to 1.5 (Python 2.5 installer). Now all bzr+ssh operations fail with the following error:

Using last location: bzr+ssh://<email address hidden>/lighty/
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 01:e2:36:2b:17:7f:82:29:59:92:bd:e2:1d:15:28:24
Connection abandoned.
bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)

Before I upgraded, managing host keys was as simple as adding a line to C:\Documents and Settings\user\Application Data\bazaar\2.0\ssh_host_keys. But this new version of bzr isn't even accessing ssh_host_keys (checked with FileMon.) And I have no idea where "the registry" is located. I have verified that C:\Documents and Settings\user\Application Data\bazaar\2.0\ssh_host_keys is updated and has the correct information.

Here's the traceback, in case it helps:

0.351 encoding stdout as sys.stdout encoding 'cp437'
0.361 bzr arguments: [u'missing', u'-v']
0.361 looking for plugins in C:/Documents and Settings/user/Application Data/bazaar/2.0/plugins
0.361 looking for plugins in C:\bin\Python25\lib\site-packages\bzrlib\plugins
0.361 Plugin name __init__ already loaded
0.361 Plugin name __init__ already loaded
0.871 encoding stdout as sys.stdout encoding 'cp437'
1.352 ssh implementation is Putty's plink.
2.484 Traceback (most recent call last):
  File "C:\bin\Python25\Lib\site-packages\bzrlib\commands.py", line 846, in run_bzr_catch_errors
    return run_bzr(argv)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\commands.py", line 797, in run_bzr
    ret = run(*run_argv)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\commands.py", line 499, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\commands.py", line 807, in ignore_pipe
    result = func(*args, **kwargs)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\builtins.py", line 3322, in run
    remote_branch = Branch.open(other_branch)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\branch.py", line 107, in open
    possible_transports=possible_transports)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\bzrdir.py", line 667, in open
    return BzrDir.open_from_transport(t, _unsupported=_unsupported)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\bzrdir.py", line 704, in open_from_transport
    redirected)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\transport\__init__.py", line 1616, in do_catching_redirections
    return action(transport)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\bzrdir.py", line 681, in find_format
    transport, _server_formats=_server_formats)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\bzrdir.py", line 1440, in find_format
    return format.probe_transport(transport)
  File "C:\bin\Python25\Lib\site-packages\bzrlib\bzrdir.py", line 2398, in probe_transport
    server_version = medium.protocol_version()
  File "C:\bin\Python25\Lib\site-packages\bzrlib\smart\medium.py", line 421, in protocol_version
    self._protocol_version = client_protocol.query_version()
  File "C:\bin\Python25\Lib\site-packages\bzrlib\smart\protocol.py", line 621, in query_version
    resp = self.read_response_tuple()
  File "C:\bin\Python25\Lib\site-packages\bzrlib\smart\protocol.py", line 544, in read_response_tuple
    result = self._recv_tuple()
  File "C:\bin\Python25\Lib\site-packages\bzrlib\smart\protocol.py", line 602, in _recv_tuple
    return _decode_tuple(self._recv_line())
  File "C:\bin\Python25\Lib\site-packages\bzrlib\smart\protocol.py", line 614, in _recv_line
    "(and try -Dhpss if further diagnosis is required)")
ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)

2.484 return code 3

Anyone know what I'm doing wrong? Thanks!

[Rolly (hachirota)]

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

[Martin Pool (mbp)]

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

[Martin Pool (mbp)]

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.

[Martin Pool (mbp)]

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.

[Martin Pool (mbp)]

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?

[Martin Pool (mbp)]

Sorry Stas, I typed the wrong user name.

Alexander, can you confirm this fix?

[Robert Collins (lifeless)]

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

[John A Meinel (jameinel)]

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...

[Alexander Belchenko (bialix)]

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.

[Alexander Belchenko (bialix)]

Vote to mark it Won't Fix.

[Martin Pool (mbp)]

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.