This is a discussion on Re: how to automate public key authentication when server dual-boots - openssh ; Hi John, you have to overwrite both the public key and the private key. In fact, the first time you connect to a ssh enabled server, this server sends its own fingerprint calculate from the public key, if you accept ...
you have to overwrite both the public key and the private key. In fact,
the first time you connect to a ssh enabled server, this server sends its
own fingerprint calculate from the public key, if you accept it, this server
with this key will be trust by you. In this way, if the key change, it should
mean someone get the ip and try to get your password, or someone modify your
server. In your case, it is only you who have generated two different sets of
keys for the same IP. The simplest way to do, is to put in place the same key
pair, as you suggested. Then, you know (ie you trust) your two linux install ...
The file containings the trust servers is ~/.ssh/known_hosts, you can also
delete the entry of the server in this file to allow to connect to both
server, but each time you reboot, you have to delete the entr, then to say
again yes the first time you reconnect.
I hope it is clear (not evident )
John Lumby said the following on 07.06.2006 18:03:
> I have a hopefully simple question on setup for sshd.
> I recently switched my server from rshd to sshd and it works fine. I am
> using public key authentication.
> However the wrinkle is that this server has two different linux
> partitions which I need to alternate between (strictly only one at a
> time, not a virtual machine setup). With rshd they both appeared to
> be identical as far as rsh authentication. With sshd, when I booted
> the second one, and then tried an ssh to it from another machine, of
> course I got
> WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
> ... rsa fingerprint ... etc etc.
> I realize that this is exactly what sshd is designed to do, to detact
> impersonation of the server, but unfortunately that's exactly what I
> need to do (but of course don't want any other impersonator to be
> I could try just overwriting the second server partition's
> with the first one - but is that the right way? Would that cause other
> problems? Hoping someone else has come across this and there is
> some recognized solution to this.