ssh RSA key fingerprint differs from SOLVED

Shing-Fat (Fred) Ma fma "at"
Thu, 03 Jan 2002 00:08:31 +0000

I'm not sure if these should have been obvious or not, but as a newbie,
I've run into a few details that could save days.  These pertain to
Frank Stajano's instructions (,
which are based on a system different from my own.  I'm using cygwin
on WinME to initate an ssh to a solaris8 box.  The viewer is to run on WinME
while the vncserver is to run on the sunbox.  These two boxes negotiated
and decided on protocol 2.  From the look of things, it looks as if the important
file in my case is the RSA key file  on the sun box, though I'm not sure if a
different method of authentication may be used on someone else's system.

This is where I had to deviate from Stajano's instructions.  Instead of copying
the content of /etc/, I had to run

     ssh-keygen -l -f /etc/

and copy down the key that was generated.  When I run ssh my laptop's
cygwin, I get asked to confirm that I recognize the key that it displays, so
I compare it with the key I copied.  It matches.  That's how I get logged
into the remote vncserver host.

It probably isn't a good idea to display the key fingerprint over an insecure
VNC display.

Another thing is that the vncserver must already be running on the remote
host before I try to ssh in.  Otherwise, I get a message that initiating a 2nd
channel is administratively prohibited (something like that).

In Stajano's example, he used display :4, but for some reason I can't
imagine, this was already used (not by vnc, since "ps -ef" didn't show
vncservers besides my own).  However, things worked fine when I used
display :7.

Finally, I made the mistake of writing a wrapper script called "vncs", which
calls vncserver with a few default options and appends any options supplied
to vncs, including the display specification if any.  Well, it turns out the
display specification has to be the first argument supplied to vncserver.
A mistake most people won't make, but here it is for any poor soul who did.

Despite the things I tried out of desparation in my previous posting, I did
not have to create my own keys with ssh-keygen.

Finally, some concerns were expressed to me about the bandwidth
degradation in using ssh.  I didn't notice any, though Stajano's page does
warn about having to explicitly choose bandwidth efficient encoding
(e.g. tight) for slow channels, since the weird ssh configuration causes
the encoding to default to a scheme that is only good for wide bandwidth

So in payment for using up so much bandwidth on this mailing list,
hope this helps!

Fred Ma
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Ottawa, Ontario
Canada     K1S 5B6
fma "at"
To unsubscribe, mail majordomo "at" with the line:
'unsubscribe vnc-list' in the message BODY
See also: