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 [EMAIL PROTECTED] 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. Fred -------------------------------------------------------------------------- Fred Ma Department of Electronics Carleton University, Mackenzie Building 1125 Colonel By Drive Ottawa, Ontario Canada K1S 5B6 [EMAIL PROTECTED] ========================================================================== > Date: Mon, 31 Dec 2001 18:34:23 +1100 > From: Cameron Simpson <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> >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 > or > 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 [EMAIL PROTECTED] > | > | 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@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: > p > which should print the decimal version of that value > - compare with your target host's public key > > | Also, I am not "root". > > The "root@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 [EMAIL PROTECTED] http://www.zip.com.au/~cs/ > > Network Planning Constraint Of The Month: > You can't send bits over a non-existant link. > - Valdis Kletnieks <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------