ssh RSA key fingerprint differs from ssh_host_key.pub
Shing-Fat (Fred) Ma
fma "at" doe.carleton.ca
Tue, 01 Jan 2002 11:35:05 +0000
Thanks, Scanman and Cameron.
Cameron, most of what you say makes sense. But I'm having problems with
some of it.
First, I gather from your email that the remote computer I'm trying to access
(MachineName below) is running an ssh daemon that speaks protocol 1
by the fact that the it's /etc/ssh_host_key.pub consists only of decimal
digits? And the fact that my cygwin ssh spits out hex numbers is because
it is speaking protocol 2? The reason I want to make sure is because
I'm not really sure if the ssh daemon on MachineName is restricted to
protocol 1. Sure, the MachineName's ssh man pages contain only the part
corresponding to the protocol 1 on my cygwin ssh man page, but that might
just be the man pages setup. In contrast, a "which ssh" on MachineName
shows two paths, both respond to "ssh -help" with options that allow the
forcing of protocol 2 as well as 1. And just to complicate matters (at least
for me), I'm what that says about the ssh daemon itself, since I'm not sure
if it even gets started by the ssh command.
Also, cygwin's ssh-keygen defaults to rsa1. But I used your rsa1 option
anyway. No luck. Just to be sure, I also used "ssh -1 -L" to force
protocol 1. Just as a side-question, is it secure to ftp these these
"key" files back and forth?
A more overriding hint about what I might be doing is that the key
fingerprint consists of 16 hex numbers separated by colons, each
hex number being two hex digits. So it looks like 16 bytes, or 32 hex
digits. This is true of both the fingerprint shown to me by ssh-keygen
as well as the fingerprint shown to me by the "ssh -1 -L" command.
I pumped the latter through dc (after removing all colons and making
all letters uppercase to avoid dc errors), but the result doesn't even
remotely approach a 320 digit decimal number (the one from
/etc/ssh_host_key.pub). Furthermore, the ssh_host_key.pub file
has not one but three numbers (the first two are very short, but the
third number is about 320 digits long, all decimal). So do I ignore
the first two and try to solve why the 3rd one is so grossly
mismatched with the key fingerprint from "ssh -1 -L"?
Finally, last argument to ssh, I tried specifying the ssh daemon
host as both MachineName.blah.bleh as well as
fma "at" MachineName.blah.bleh. For each of these, I tried ssh
with and without -1 option, for a total of 4 combinations. The
key fingeprint I'm asked to accept depends only on the "-1"
option, and they are always the same length as above (much
shorter than the one in MachineName's ssh_host_key.pub file).
It would seem to me that it should matter whether I include fma@
or not, because how else would MachineName know where to
look for ~/.ssh/authorized_keys?
Finally (final one), cygwin doesn't have dc, so I ended up accessing
the sun box at the company where I intern. They provide a secure
connection. However, I don't suppose it would be wise to use the
dc at Carleton University via VNC since connections to there are insecure
until I get this ssh going? Neither would it be wise to "cat" the
ssh_host_key.pub on MachineName for a peek for the same reason?
OR, doesn't it matter since it is after all a "public" key?
Thanks for wising me up on these issues.
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Canada K1S 5B6
fma "at" doe.carleton.ca
> Date: Mon, 31 Dec 2001 18:34:23 +1100
> From: Cameron Simpson <cs "at" zip.com.au>
> Subject: proper answer re: ssh RSA key fingerprint differs from ssh_host_key.pub
> On Sun, Dec 30, 2001 at 06:00:29PM -0500, Shing-Fat (Fred) Ma <fma "at" doe.carleton.ca> wrote:
> | I am mostly following http://www.uk.research.att.com/vnc/sshwin.html .
> | Since I'm running cygwin on WinME, I'm using their built-in ssh. Its
> | man page includes both protocol 1 and protocol 2. I'm accessing a
> | Solaris8 box whose ssh man page seems to only have protocol 1 stuff, so
> | I assume that is what is being used. In particular, the message I'm
> | going to ask relates to RSA, which seems to fall under protocol 1.
> Protocol 2 uses both RSA and DSA keys.
> When making a personal keypair you want to say:
> ssh-keygen -t rsa1
> to make a pair for use with a protocol 1 server and:
> ssh-keygen -t rsa
> ssh-keygen -t dsa
> to make a pair for use with a protocol 2 server.
> Since I have to deal with both I have an rsa1 key pair and a dsa key pair.
> | Here's is what happens when I follow the above web instructions.
> | From the cygwin bash prompt, I tried both
> | ssh -L 5954:MachineName.doe.carleton.ca:5904 MachineName.doe.carleton.ca
> | ssh -L 5954:MachineName.doe.carleton.ca:5904 fma "at" MachineName.doe.carleton.ca
> | The response is
> | The authenticity of host 'MachineName.doe.carleton.ca (<some IP number:>)' can't be established.
> | RSA key fingerprint is <long series of 2-digit hex numbers separated by ":">
> | Are you sure you want to continue connecting (yes/no)?
> | As per the web instructions, I checked the file /etc/ssh_host_key.pub which I ftp'd from
> | MachineName.doe.carleton.ca. They do not appear the same. In fact, the file I ftp'd
> | has only one line with 3 numbers followed by "root "at" MachineName". The 3rd number
> | is almost 320 digits long and appears entirely decimal.
> This is an unfortunate implementation flaw in ssh2 and openssh (which you are
> using: they recite keys in hex only. You can convert one to the other with the
> "dc" command, which does arbitrary precision arithmetic:
> - copy the hex key into your cut/paste buffer
> - fire up dc at you shell prompt
> % dc
> - dc has no prompt - don't worry
> - type this:
> 16 i
> this sets dc's input radix to 16 (to read hex values);
> its output radix is already 10 (decimal - the default)
> - paste in your hex value and press return
> - type this:
> which should print the decimal version of that value
> - compare with your target host's public key
> | Also, I am not "root".
> The "root "at" MachineName" is just a comment stuck on the server's host key
> when it is made. So that's actually expected, and ok.
> | So I
> | answer "no" to continuing.
> Perform the comparison above. If they match you can and should say "yes".
> | At this point, I departed from the instructions. According to the ssh man pages for
> | RSA authentication, I run ssh-keygen from the WinME viewer side, which I do from
> | the cygwin bash prompt. I am given a RSA key fingerprint similar to that in the response
> | above but with different digits, which I record. I then ftp'd the created file "identity.pub" to
> | MachineName as "~fma/.ssh/authorized_keys" and run both of the above ssh commands.
> Ok. You've done two things wrong here (sort of).
> Ssh-keygen is giving you an rsa key for protocol two. It is of no use on
> your target server because it speaks protocol 1. You can tell the two
> formats apart by eye because the protocol two keys are base64 encoded
> and the protocol 1 keys are decimal.
> Also, you can't put protocol 2 public keys into the authorized_key file.
> You use the authorized_keys2 file (note trailing "2" on the filename).
> Same idea though.
> However, since you have an ssh1 server, you will be using plain
> "authorized_keys" so it remains merely to make a protocol 1 key pair.
> Say this:
> ssh-keygen -t rsa1
> and proceed as before.
> | However, the returned RSA key fingerprint is the same as before i.e. differs from the one
> | shown to me by ssh-keygen . Of course, I respond with "no" to that.
> The RSA key fingerprint is the server host key - it will always differ
> from your personal key pair.
> Your personal keypair is to assure the server that it's _you_ logging in.
> The host key pair is to assure you that you're actually connecting to
> the server you expect.
> Does this make things any clearer?
> - --
> Cameron Simpson, DoD#743 cs "at" zip.com.au http://www.zip.com.au/~cs/
> Network Planning Constraint Of The Month:
> You can't send bits over a non-existant link.
> - Valdis Kletnieks <valdis "at" vtvm1.cc.vt.edu>
To unsubscribe, mail majordomo "at" uk.research.att.com with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html