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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev