ssh host keys on cloned virtual machines
Nico Kadel-Garcia
nkadel at gmail.com
Sat Feb 25 23:50:57 AEDT 2023
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.
More information about the openssh-unix-dev
mailing list