openssh unix dev - Feb 2023 - ssh host keys on cloned virtual machines

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.

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)
-------------- 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/20230225/bbb016c4/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/20230225/bbb016c4/attachment-0001.asc>