On 03/15/2019 12:49 AM, Jeremy Lin wrote: > [...] connecting to hosts where the host key > changes frequently. I realize this is a fairly niche use case [...] Imagine sysadminning a boatload of VMs getting IPs from a dynamic pool, a la $ for ADDR in $CUSTOMER_1_RANGE $CUSTOMER_2_RANGE... ; do > ping -c 1 -w 2 $ADDR >/dev/null 2>&1 && ssh root@$ADDR do_urgent_fix > done , and it mightn't be that much of a niche anymore ... > [...] developing software for devices that often get reimaged > (resulting in a host key change) [...] If the host keypair(s) are truly useless for identifying a *single*, short-lived target host, my suggestion would be to include "global" keypairs into the image (and have them still replaced once in a while). That would at least protect clients from a fake host set up by someone who doesn't have access to the image or the legit hosts. (Or from accidentally shredding a genuine "permanent" system that somehow obtained the DNS name / IP of a short-lived one.) If, however, reimaging is a standardized process that might allow the new host pubkey(s) to be collected and distributed in one fell swoop, there's the GlobalKnownHostsFile setting which is *supposed* to point to a file maintained by the *sysadmins* ... Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
