How can I have the same ssh key for dual boot (ssh-keygen)

[Nico Kadel-Garcia]

On Tue, Apr 1, 2014 at 4:48 AM, Philip Hands <phil at hands.com> wrote:
> Kevin Wilson <wkevils at gmail.com> writes:
>
>> I use:
>> ssh-keygen -t rsa
>> to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on
>> other machines in order to permit ssh to these machines without being
>> asked for a password.
>>
>> The thing is that I have dual boot on this machine: one for fedora and
>> one for ubuntu. The two key files which were generated on these machine
>> are different.
>>
>> Is there a way so that I will have the same key file for both these fedora
>> and
>> ubuntu ?
>
> As mentioned by others, there is a way to do this, but I'd suggest that
> you shouldn't want to.
>
> What's wrong with having an additional key in the authorized_keys file?

It's not an "additoinal" key. It's a mismatched key for the same
hostname in DNS and the same IP address. This causes every SSH client
on the planet to complain about the mismatch, unless you've
specifically disabled that check in your client configuration. And
there is *no* tool besides a text editor for updating such changed
records in the UNIX/Linux client text based client world besides a
text editor.

This is partly why some folks would like an authentication procedure
for host keys, so such changed keys can be signed by a trustworthy
upstream source and simply accepted like signed SSL keys.

> If the thing you're trying to avoid is the pain of installing the keys
> twice, well if you're using ssh-copy-id just add the public key for the
> other machine into the id_*.pub file on each, then whichever you install
> From will authorise both.  If you've got a more structured way of
> installing the keys (i.e. chengine, puppet etc. etc.) then just add both
> keys to your config and you're done.
>
> This seems preferable both on the basis that you're not having to fiddle
> with the host keys in possibly assumption-breaking ways, but also
> because it may come to pass that one of the keys is somehow compromised
> while the other remains secure, in which case you'll be able to boot the
> secure system and fix things.

Accepting this sort of user pain is how IT departments get hated. It
might be acceptable for one person who built the system to deal with
the yammering about mismatched keys when trying to do work, it would
not be acceptable in most development envirornments. And it's an
ongoing problem for server rebuilds from PXE or for SSH services
behind a load balancer.