As far as I can tell, there currently isn't a straightforward way to use password authentication for connecting to hosts where the host key changes frequently. I realize this is a fairly niche use case, but when developing software for devices that often get reimaged (resulting in a host key change), it can get pretty tedious to attempt to connect, get a warning, remove the old host key via text editor or "ssh-keygen -R", and then connect again. I'd like to propose adding a new StrictHostKeyChecking option, named something like "ask-update" or "ask-to-update". This would be like "ask", except it would prompt the user to update a host key if it has changed (after printing a suitably scary warning). When connecting to an unknown host, it would be equivalent to "ask". I expect users would enable it explicitly for a limited set of hosts, e.g. by adding a config section like Host 192.168.0.* StrictHostKeyChecking ask-update If this idea sounds acceptable, I could potentially work on it, but I don't mind at all if someone else is interested in doing it. Thanks, Jeremy
Out of curiosity, why don't you just not store a host key for such systems? That's what we do: UserKnownHostsFile /dev/null Historically I would have been interested in such a thing, but I've long since given up.
Simple, I wasn't aware of that option, and that approach never occurred to me. :) Thanks, that should be an effective workaround. I think the extra StrictHostKeyChecking option would be easier for someone to find, and arguably has some minor security benefit, but it's no longer clear to me whether it would be worth the effort. Thanks again. Jeremy On Thu, Mar 14, 2019 at 4:59 PM Josh Soref <jsoref at gmail.com> wrote:> > Out of curiosity, why don't you just not store a host key for such systems? That's what we do: > UserKnownHostsFile /dev/null > > Historically I would have been interested in such a thing, but I've long since given up.
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20190315/b9e56543/attachment.p7s>
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 [...]Doesn't StrictHostKeyChecking=no do what is wanted?
On Fri, Mar 15, 2019 at 09:10:26AM +0000, Jochen Bern wrote:> 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 ...And that's when you look at using certificate based host keys. -- rgds Stephen
On Fri, Mar 15, 2019 at 2:13 AM Jochen Bern <Jochen.Bern at binect.de> wrote:> > 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* ...These are development builds of software images that will eventually be shipped to customers, so we'd strongly prefer not to hardcode any host keys since that could accidentally end up getting shipped someday.
On Thu, Mar 14, 2019 at 8:01 PM Josh Soref <jsoref at gmail.com> wrote:> > Out of curiosity, why don't you just not store a host key for such systems? > That's what we do: > UserKnownHostsFile /dev/null > > Historically I would have been interested in such a thing, but I've long > since given up.You forgot "LogLevel Error" and "StrictHostKeyCheckng no" to completely disable the use of $HOME/.ssh/known_hosts and make it shut up. If the hosts I dealt with would have consistent IP addresses and DNS tied to host keys, I'd say "this is a potential security risk". However, I deal with multiple raw OS images deployed into virtualization environments with DHCP randomized IP addresses, regenerated multiple times a day, as a matter of course. The cost of saying "flush another old key" all the time is burdensome. That much extra work is actually anti-security.