On 2/25/23 21:18, Nico Kadel-Garcia wrote: > On Sat, Feb 25, 2023 at 12:14 PM Demi Marie Obenour > <demiobenour@xxxxxxxxx> wrote: >> >> On 2/25/23 07:50, Nico Kadel-Garcia wrote: >>> On Fri, Feb 24, 2023 at 10:01 AM Jochen Bern <Jochen.Bern@xxxxxxxxx> 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)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
