@cert-authority for hostbased auth - sans shosts?

[Marian Beermann]

On 11/15/23 18:09, Chris Rapier wrote:
> On 11/11/23 9:31 PM, Damien Miller wrote:
>
>> It's not discouraged so much as rarely used. It's very useful in some
>> situations and I can think of good reasons to use it more often (e.g
>> requiring both host and user identity as part of authentication).
>>
>> It definitely has more rough edges than user publickey authentication -
>> it's harder to set up (admin only) and harder to debug, as it requires
>> access to authentication logs and we haven't put as much effort in to
>> making the logs useful and actionable when something is misconfigured.
>
> We use it extensively to manage the nodes in our HPC clusters. It ends 
> up being much less difficult to maintain that the alternatives.
>
That's our use case as well. Probably the most common use case for 
hostbased methods?

Normal key-based authentication methods would require keeping O(N*M)  
(N=number of users, M=number of nodes) items (millions) in sync: every 
user's key would need to be on every node in their 
~/.ssh/authorized_keys and every node's host key needs to be in every 
other node's /etc/ssh/known_hosts + shosts.

With hostbased only the latter part (/etc/ssh/known_hosts + shosts) is 
needed.

With @cert-authority only the shosts is needed. Which is already a 
significant advantage, because no keys need to be synced any more.

With a hypothetical /etc/ssh/authorized_keys (or an equivalent 
mechanism, like a @hostbased-authority flag in /etc/ssh/known_hosts) 
nothing would need to be synced at all (conversely: no more ssh breakage 
"from first principles"), unless the CA root has to be rotated.

Cheers, Marian