I have ssh running on my rh box <ip: 192.168.1.3> and have created a new user "admin"

then i su - admin and did a ssh-keygen -d which generated 2 keys id_dsa and id_dsa.pub

On another computer (connected via LAN) running windows i use putty to ssh

eg. c:\ putty.exe 192.168.1.3 -ssh

this pops up a warning window saying the host key is not cache and that the servers rsa2 fingerprint is

ssh-rsa 1024 47.dc.af.fz.ae ....

however on the rh server :
(admin@rhserver1 .ssh)# ssh-keygen -f id_dsa.pub -l
1024:85:c8:68:....

why is putty displaying a different public key than the one in my rh box???

am new to all this so please forgive me if this sounds like a stupid question.

I see 2 possibilities.

1- the key you generated with admin is not used, since the ssh server generated its key at install.

2- a key and a fingerprint of a key is different, hence the discrepancies

The warning you get upon connect has to do with the machine you are connecting to, regardless of what user you are connecting as.

Each machine has its own fingerprint, used to prevent other machines from impersonating it. When you connect to a machine for the first time, the dialog box you describe pops up, asking you if you want to store this key. From then on if you connect to a machine of that hostname, your ssh client compares the fingerprint of the machine you're connecting to with the fingerprint it has stored. If they match, the ssh client establishes a connection. If they do not match, the ssh client issues a warning about a possible man-in-the-middle attack.

The keypairs generated with ssh-keygen are for authenticating users, which is completely seperate and not done by default.

Hope this helps.

thanks for the explanation people...really appreciate the help im getting.

So exactly what command/s can i run on the rh box to see the server fingerprint to verify that i'm actually connected to the correct server??? and if i accept the key and connect to the machine with user admin and pwd ....where does user authentication happen?? coz i can connect without any other pop-ups for user-key verification

when you connect for the first time to an IP/hostname, it caches the fingerprint somewhere on the computer you connect from, when you accept.

every time after that, when you connect the fingerprints are compared. If they are identical, you don't get any error. If it changes it is a potential security breach and you are alerted

hth

thanks again for the explanation ugob.

what i was trying to get at ( and please forgive me if my question wasnt direct enuff) is ...how do you verify that you are connecting to the intended server on the very first try (ie before the host key is cached or 1st time connecting)?

I know my question here might sound overly paranoid ...but im really trying to get a grasp of the basic concepts and tryin to learn some basic linux administration.

On the server (assuming it's a Linux server using openssh), the server's public key should be, along with every other important non-user-specific ssh file, in /etc/ssh. Depending on whether it's an RSA or a DSA keypair, the exact filename would be:

/etc/ssh/ssh_host_rsa_key.pub

or

/etc/ssh/ssh_host_dsa_key.pub

That's what gets cached. Then, later in the connection process, the server encrypts some data (don't know what) with it's private key, stored in /etc/ssh/ssh_host_[rsa|dsa]_key. Since only the corresponding public key can decrypt a message encoded with someone's (or some host's) private key, the client can determine which of the cached keys successfully decrypts the data and if the host ascociated with that key matches the host attempting to connect.

Now, disclaimer: A lot of this is educated assumption about the way ssh works, based on my knowlege of how digital signing normally works. Even if ssh works a bit differently, it should be something like what I've described above. If anyone has more complete info, feel free to contribute.

Either way, that will hopefully answer your question.

that was EXACTLY what i was looking for ....thanks <usernamenumber>

what's all the fuss with those keys ???? that's not quite relevant unless you might be working in a bank or at NASA where security is a big deal ...

I can't tell if you're trolling or just asking so I'll give you the benefit of the doubt:

You don't have to be an important site for someone to want to steal passwords, steal data or inject data into a communication. There are lots of people who do it to anyone they can simply because they can. And since ssh makes it simple to prevent things like that from happening (almost all of the stuff we've been talking about with regard to server keys is done transpanrently to the user) then why not use ssh? It's more flexible than telnet (allows remote excecution, copying files, etc) and it's more secure.

Another big advantage of ssh for the system administrator is that you can set up secure, passwordless logins which make remote administration very simple (provided you keep the machine you're allowed passwordless access from VERY secure, of course)

Hope that helps.

Quote:

You don't have to be an important site for someone to want to steal passwords, steal data or inject data into a communication. There are lots of people who do it to anyone they can simply because they can.

I'd just like to add to this completely true point that motive to access ANY box exists, if for no other reason, JUST to relay from other then their own intended abuses to whatever is targeted. Almost exactly the same general technique that this doom thing is doing now --only by e-mail.

yeah but come on ... mass scanners are used .. none will stay to intercept your communication between small servers ..and to decrypt and stuff like that .. mostly commong bugs are exploited... everything is done as fast as could be .. so i think that being too paranoid ... it's not quite good ..i mean doesn't do bad ... but ... instead of holding on to a ssh key that went not as u expected , better upgrade the software , get some IDS , and from time to time relax... because sometimes ppl tend to overestimate kiddies . who scan all day long and night at internet cafe's ... i know how this happens ... and i know that too much paranoidism is not good most of them have linux commands in e-mails .. or on notebooks .. they don't know what they do ... but they do ... they will learn .. some day what everything is but till that day ..

katmai90210 Between IP tables, GOOD firewalls SSH, although NO Internet usage is totally safe (can't be done) -Amounts to building a yacht or ship with NO through hull fittings and that is just not realistic.. But with a good common sense and the aforementioned, it's quite possible to be reasonably secure.

katmai90210,

I hear what you're saying and it's very true that one of the basic principles of security is to find a level of security that is not so secure it makes your system(s) too difficult to use. But allow me to suggest two things:

1) Suppose someone doing a mass scan finds a hole on one of your systems and manages to root it. Very often the next thing they will try to do is set up a sniffer (this is often scripted so they don't have to know what they're doing). If the traffic on your network is unencrypted then you've just handed them the entire network instead of just one box.

2) Ssh is, if anything, _more_ usable than telnet except perhaps for having to hit 'y' the first time you connect to accept a server's key. So why would you not use ssh?

But then, maybe I'm misunderstanding you. If you're not arguing against using ssh but are instead saying that it's overkill to stress about server keys and stuff like that, well then

1) The original poster was just wanting to understand how they work and there's never anything wrong with that.

2) If a server's key changes, there's generally only two possible explainations: Either you've reinstalled that server or someone is spoofing that machine's IP and ssh is letting you know. It doesn't happen by accident. So if it's as unlikely as you say for this to happen on a small network then the admin will never run into it and it's a non-issue. But suppose it _does_ happen. Would you rather be the admin who knows what this means or the one who just accepts the new key because "that kind of thing doesn't happen on small networks"?

i'm not against using keys ... and i'm not argueing against ssh i use ssh on my server ... but i am saying that you should preoccupate more in upgrading your system and having decent updates on it ... then i think i am positively sure that your box will not be rooted .... unless some group of coders start creating an exploit just for you .... which i definitely doubt we present so much interest ....