ssh host keys on cloned virtual machines

[Nico Kadel-Garcia]

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.