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

On 23.03.21 06:42, Nico Kadel-Garcia wrote:
> If I want to delete a hostkey entry, and there is none to be found,
> shouldn't that be considered a successful operation?
I can think of (easily more than) two scenarios where someone would want
to run such a command in the first place:

-- An admin performing cleanups on users' known_hosts file after a
server changed keypairs or got decommissioned, where not finding the old
pubkeys in some of the user configs would be expected and ignored

-- A user who has had strict hostkey checking block his login and tries
to fix the problem, where the command *failing* to (semi-)fix the
problem is something he definitely wants to know about

You can't have one and the same command do *both*.

If anything, the reaction of "ssh-keygen -R ..." to a missing
known_hosts file should be consistent with the outcome of it not finding
a matching key therein to delete (which is to output an error message
but still do an exit(0), apparently).

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210324/aa42d51a/attachment-0001.p7s>

On Wed, Mar 24, 2021 at 5:45 AM Jochen Bern <Jochen.Bern at binect.de>
wrote:
>
> On 23.03.21 06:42, Nico Kadel-Garcia wrote:
> > If I want to delete a hostkey entry, and there is none to be found,
> > shouldn't that be considered a successful operation?
>
> I can think of (easily more than) two scenarios where someone would want
> to run such a command in the first place:
>
> -- An admin performing cleanups on users' known_hosts file after a
> server changed keypairs or got decommissioned, where not finding the old
> pubkeys in some of the user configs would be expected and ignored
>
> -- A user who has had strict hostkey checking block his login and tries
> to fix the problem, where the command *failing* to (semi-)fix the
> problem is something he definitely wants to know about
>
> You can't have one and the same command do *both*.
>
> If anything, the reaction of "ssh-keygen -R ..." to a missing
> known_hosts file should be consistent with the outcome of it not finding
> a matching key therein to delete (which is to output an error message
> but still do an exit(0), apparently).
This is why I'm suggesting should be the default.