openssh upgrade causes havoc !

[Michael Murphy_2]

hello - ever heard of an upgrade to openssh causing all of scp scripts to start complaining with "authinticity of host" errors? Any solution with known hosts or authorized_keys to keep it from happening? thanks

[Steven Schweda]

> [...] upgrade [...]

On what?

uname -a

Of what, exactly, from what to what?

ssh -V
[Before and after would be good.]

As usual, copy+paste of an actual error
message might be more helpful than some loose
interpretation of what you saw in some
undisclosed context.

If you somehow generated new host keys, then
things which remember an old host key may
rightly be quizical when you come around with
the new host key, claiming to be the same old
fellow.

Cleaning the junk out of known_hosts data
collections should help, but then you can
expect to see the usual first-time messages
when the server system(s) see the new key for
the first time.

If you can find and replace the old host
keys, then you might avoid some work.
(Assuming that the old keys would be
compatible with the new software. Hard to be
confident, given practically no useful info
about anything, but running the experiment
might be easy.)

[Michael Murphy_2]

Ummm - maybe I was in the middle of the issue and I didn't have time collect every minutia of detail - and was trying to find a quick fix - ever think of that????

[Steven Schweda]

> Ummm - maybe I was in the middle of the
> issue [...]

Is that anything like a _problem_?

> [...] ever think of that????

Sadly, my (very weak) psychic powers are not
strengthened by the urgency of your
situation, so it doesn't really matter, does
it? If you want more than guesswork, then you
may need to supply some useful background
info, irregardful. I see that you had time
to whine, though.

[Matti_Kurkela · Accepted solution]

When a SSH server (any type) is installed for the first time, it will generate a set of host keys. Each time a client connects to that server for the first time, it receives and records the public part of that key. On subsequent connections, that key is used to verify the identity of the server.

If you accidentally deleted the original host keys (or did not move them to the correct directory, or convert them to the right format if you upgraded from commercial SSH to OpenSSH), then all your clients that have connected to the server before will receive warnings. Sshd cannot function without host keys, so if the host keys are not available or seem corrupted, sshd will regenerate them.

The easiest way for you to fix this would be to restore the original host keys from your old backups (you DO have backups, right?), convert them to the OpenSSH format if necessary, and then replace the current hostkeys with the original ones. But if some of your clients have already accepted the new key, those clients will now see the old key as "wrong" and the new key as "right". So you will need to tell your clients what is happening in every case. You cannot force the clients to accept the new key from the server side: that would defeat the purpose of having the host key.

If you cannot find the old host keys, the client-side workaround is to remove the old host key record from the client-side ~/.ssh/known_hosts files (or from Windows registry, or from whatever storage method the client uses), then connect once and accept the new key.

If your version of ssh client has the HashKnownHosts setting enabled (as is the default for new versions of OpenSSH), then you cannot simply read the known_hosts file to identify the correct line to remove: the host keys are hashed to make them unidentifiable by eye. In that case, you must make one connection attempt and look at the error message presented to the client to find the number of the line to remove from the client's known_hosts file. You may need to do this twice for some OpenSSH versions, to find and remove both by-hostname and by-IP host key records.

MK

[Viktor Balogh]

> If your version of ssh client has the HashKnownHosts setting enabled....

I'm not 100% sure but maybe a simple

# ssh-keygen -R hostname

would solve the issue even if known_hosts is hashed. Worth a try...

[Steve Post]

"hello - ever heard of an upgrade to openssh causing all of scp scripts to start complaining with "authinticity of host" errors? "

Yes. This happens anytime you change the software because you are using a new key. It complains about the potential Man in the Middle attack.

"Any solution with known hosts or authorized_keys to keep it from happening? "

Looks like you got your answers above.

[Michael Murphy_2]

Solution was in the host keys - they can be copied during upgrade to cause no prompt - thanks to the LATER helpful comments (first snide ones had me thinking forums had fallen to a new low with trolls - thanks to all the later replies that have renewed my faith in the helpful nature of the forum!)

[Steven Schweda]

> Solution was in the host keys [...]

It's too bad that that first "snide" response
didn't suggest that. Oh, wait ...

[Steve Post]

It's a matter of perspective. I know the "helpful info" in my mind seems to be like fluffy bunnies. But it comes out in forums as rabid weasels.