openssh unix dev - Mar 2021 - "ssh-keygen -R hostname" errors out with non-existent known_hosts

On Wed, 24 Mar 2021, Thorsten Glaser wrote:
> On Tue, 23 Mar 2021, Noah Zalev wrote:
> 
> > It may be a success according to your semantics in this instance, but
> > what about in cases where the known_host file *should* have been
> > found, but wasn't?
> 
> What do you care?
Because known_hosts not existing is an abnormal condition for a tool
that is asked to modify known_hosts.

On Tue, Mar 23, 2021 at 11:53 PM Damien Miller <djm at mindrot.org>
wrote:
>
> On Wed, 24 Mar 2021, Thorsten Glaser wrote:
>
> > On Tue, 23 Mar 2021, Noah Zalev wrote:
> >
> > > It may be a success according to your semantics in this instance,
but
> > > what about in cases where the known_host file *should* have been
> > > found, but wasn't?
> >
> > What do you care?
>
> Because known_hosts not existing is an abnormal condition for a tool
> that is asked to modify known_hosts.
It's frequent in setups that don't generate known_hosts at all, due to
IP and hostkey drift and poor local DNS which is startlingly common in
small networks and dynamically generated clusters. It's also common in
brand new docker environments or newly built host images, unless
someone defines a procedure to build a .ssh/known_hosts file as part
of creating the image. It also happens when people do "user -r" for a
system account, and forget to use the "-m" option to create a home
directory. Those accounts are going to have issues *generating* a
known_hosts account, but I think it makes more sense to have that fail
at a step that is supposed to create or update such an entry,  not one
that is supposed to delete entries.

The one time I could see it as useful to error out is when the
account's home directory is expected to exist, via a filesystem or NFS
mount , and is enitrely unavailable. That.... gets a bit peculiar, and
I'd prefer not to try to outsmart everyone else's potential conditions
and make people fail in what is not that rare a circumstance.