ssh host keys on cloned virtual machines

[Demi Marie Obenour]

On 2/25/23 21:18, Nico Kadel-Garcia wrote:
> On Sat, Feb 25, 2023 at 12:14 PM Demi Marie Obenour
> <demiobenour at gmail.com> wrote:
>>
>> On 2/25/23 07:50, Nico Kadel-Garcia wrote:
>>> On Fri, Feb 24, 2023 at 10:01 AM Jochen Bern <Jochen.Bern at binect.de> wrote:
>>>>
>>>> On 24.02.23 12:58, Keine Eile wrote:
>>>>> does any one of you have a best practice on renewing ssh host keys on
>>>>> cloned machines?
>>>>> I have a customer who never thought about that, while cloning all VMs
>>>>> from one template. Now all machines have the exact same host key.
>>>>> My approach would be to store a machines MAC address(es). Then when
>>>>> starting the sshd.service, check if this MAC has changed. If so, remove
>>>>> all host keys, let sshd create new ones.
>>>>
>>>> Strictly speaking, *if* you have an interest to make sure that *every*
>>>> VM gets unique host keypairs, then you should implement a cleanup
>>>> routine that takes care of "everything"¹ that matters to you.
>>>
>>> These vagaries are why many environments simply disable the validation
>>> of hostkeys in their .ssh/config settings and move on to work that is
>>> of some more effective use to their workplace. I've encountered,
>>> several times, when sites relied on extensive use of SSH key managed
>>> git access and shattered their deployment systems when the git server
>>> got moved and hostkeys were either incorrectly migrated or the IP was
>>> a re-used IP of a previously accessed SSH target. Hilarity ensued.
>>> This kind of hand-tuning of every deployment rapidly becomes a waste
>>> of admin time and serves little purpose without very tight control of
>>> the "known_hosts", which can be overridden by local users anyway.
>>
>> Are SSH host certificates the solution?
>> --
>> Sincerely,
>> Demi Marie Obenour (she/her/hers)
> 
> Host key certificates are a solution to how to spend billable hours
> making someone feel good about their technological superiority without
> actually resolving the problem. You'd have to deploy the root
> certificates to all of the clients, and they become another
> unpredictable source of failure for people's laptop or new testing
> server setups. There are problems they address, of certain high
> security environments where you really, really care if someone spoofs
> your DNS or IP address, but the resulting blocked communications are
> far more likely to be blocking legitimate traffic, not intruders.
> 
> I'm also a bit snarky about the time spent to set up the service,
> publish the relevant root certificates generally and adjust the
> ssh_config settings, time far better spent elsewhere.

What *is* a good solution, then?  Disabling host key checking is not
a good solution.  What about embedding the host key fingerprint in the
domain somehow?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB288B55FFF9C22C1.asc
Type: application/pgp-keys
Size: 4885 bytes
Desc: OpenPGP public key
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20230226/0303b486/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20230226/0303b486/attachment-0001.asc>