Human readable .ssh/known_hosts?

Nico Kadel-Garcia nkadel at gmail.com
Wed Sep 30 10:59:32 AEST 2020


On Tue, Sep 29, 2020 at 8:07 PM Damien Miller <djm at mindrot.org> wrote:
>
> On Tue, 29 Sep 2020, Nico Kadel-Garcia wrote:
>
> > There are setups SSH targets where it is useful for, primarily
> > externally and consistentlyconfigured hosts with stable DNS and
> > hostkeys, such as github or gitlab. But for internal services, it's
> > generally far more trouble than it's worth.

Sorry for typos. I'm due for eye surgery on my *other* eye, which got canceled.

> FWIW I think this is bad advice.
>
> Services are only "internal" to the extent that you can trust your network.
> Search "SSL added and removed here" for a practical demonstration of this
> assumption yielding undesirable results.

Stable hostkeys are theoretically useful, but in practice have caused
*far* more service disruption than they've prevented abuse. Few SSH
users are cautious enough and thorough enough to review mismatched
keys on an individual basis. The nearly universal "fix" is to simply
delete $HOME/.sh/known_hosts, to clear your cache, and start it over
from scratch. Clearing the keys is hindered by the hasing of the
entries.

> Disabling hostkey checking is a big hammer, but occasionally useful for
> lab environments. Generally I recommend that people who are having trouble
> with hostkey management consider using host certificates.

Yes, it is a big hammer. It's a big hammer for a problem that,
thinking back, I've needed to use it or some more arcane hammer for
the same problem professionally at least once a year since.... 1995?
When ssh-1 was first written?

Signing the hostkeys means the labor and management of signing the
hostkeys. It's time, work, and money for the servers, and time, work,
and money configuring the clients to require them. When you're
managing more than 10,000 servers, with a crew of 30, .and some fool
mishandles hostkey preservation for an OS deployment..... it's a nasty
problem. That was in.... 2000?

Signed Hostkeys since OpenSSH 5.4 are a possibly better approach if
you're actually concerned about SSH hostkey consistency. But the
additional certificate signature is extra time, work, and money that
very few environments, even large environments, are weilling to
invest. The problem is especially drastic for git servers. Github and
gitlab are consistent about the host keys., but many environments fail
to preserve hostkeys when they build or update their git servers. I
have..... stories about that one.


More information about the openssh-unix-dev mailing list