SSH Keys

[Duffs]

Hi,

I have quite a number of servers (HP-UX, Solaris & Linux) which I access via a Linux hopping station which I can ssh straight into without the task of having to enter a password.

Today I built a new server and experienced difficulty ssh'ing onto it from my hopping station. I used the same key as I had used on all the other servers. So I generated a new key from my hopping station and placed it in the authorized_keys file of my new server i.e.

# ssh-keygen -t dsa -N ""

Some time after this I noticed that any other server I try to ssh onto prompts me for the password. Can someone confirm if this is what has happened and if there is a quick way of rectifying this?

Rgds,
D

[Jaime Bolanos Rojas.]

Duffs,

You might be able to find what you are looking for on this post:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1226880

Regards,

Jaime.

[Mel Burslan]

from what you described, it sounds like you have an expired password on all the machines that is giving you a password prompt.

to me this is a common occurance when I unleash a new set of servers where I usually copy the user id's from the old machine to the new machine, along with the ssh keys. Since we have a 90 day password lifetime, at the end of the 90 day period (from the date of the source system's password change) all of these servers will deny no-passphrase login attempts from ssh connection.

if you have a telnet connection, most probably it will work and let you login interactively and let you change your password as you login.

Just my guess. Take it with a grain of salt and hope it helps.

[Steven Schweda]

So, as I read it, things worked as desired
with all the old servers. Then you
"generated a new key" on your Linux system.
And now, things don't work as before on the
old servers.

It sounds to me as if you changed the key
files on your Linux system, and you didn't
tell your old servers about the new keys.
Why _wouldn't_ this break things on the old
servers?

Why didn't you copy the old key file(s) to
the new server?

[Ralph Grothe · Accepted solution]

Usually, when you create a pair of RSA keys by ssh-keygen and omit the -f option/file argument then you will be asked to confirm the filename (without extension) where the utility should place the keys.
You may inadvertently have overwritten your previous key pair thus by having confirmed with CR.
That would be bad because you now would have to distribute the new public key to all your other remote targets (if you haven't got a backup).
Remember to either use the -i option with your ssh client to specify which identity file (i.e. private key) to use for your current ssh target.
Or, to ease typing/remembering, edit in your the file $HOME/.ssh/config and use "Host" stanzas along with the "IdentityFile" directive whose value has to be the path to the private key required to login on that host.
Please, have a look at man ssh_config for details and explanation of a myriad of other viable ssh client options.

[Duffs]

Thanks for the feedback lads.

Steven, "Why didn't you copy the old key file(s) to the new server?" - I did but this is where I encountered the issue as it didn't work (I'll get back to this in a second). Anyway, my main pitfall was I didn't realise that the new key gen would overwrite the current keys; lesson learned eh?

Once I recovered the public and private keys from backup, problem resolved.

So back to my original issue - I copied the old key file from my hopping station to the newly build server (/root/.ssh/authorized_keys) but get the following error:

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
1b:69:cf:74:82:0c:68:12:e2:54:ec:6d:95:c9:8a:fb.
Please contact your system administrator.

I have removed the entry on the known_hosts file on the hopping station but still no joy, any ideas?

Thanks,
D.

[Ralph Grothe]

Probably there is a second occurrence of a host key with an offending fingerprint in your client's known_hosts?

Better than just deleting the line you should compare the fingerprints.
If you still get access to the remote host (or ask the admin there) you could there issue e.g.

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Then compare with the offending entry in your file.

[Steven Schweda]

> [...] I copied the old key file [...]

Exactly _which_ key files did you copy,
whence and whither? You should probably not
be copying host key files around, only your
own key files. You _make_ new host key files
on a new server.

> [...] the RSA host key has just [...]

This is a complaint about a server's host
key data, not about your personal key data.