Mailing List Archive

On 09/11/23, Marian Beermann (public@enkore.de) wrote:
> ... while OpenSSH does support using a CA in conjunction with hostbased
> authentication, it still requires a list of all authorized host names in the
> rhosts / shosts file.

I'm not familiar with the use of .rhosts/.shosts, but I don't think those are needed at all with a machine or per-user known_hosts file/files utilizing host certificates.

The known_hosts file can have patterns such as the following:

@cert-authority *.example.com ecdsa-sha2-nistp256 AAAAE2V...

Would accept the host certificate authority for *.example.com. The "Hostnames" field can be expanded as needed, and can enclude hashed hostnames.

See:
https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Certificate-based_Authentication#4._Updating_Clients_to_Acknowledge_the_Designated_Certificate_Authority

Another example (from the sshd man page)

cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...

Could that work for you?

Rory
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Fri, 10 Nov 2023, Rory Campbell-Lange wrote:

> On 09/11/23, Marian Beermann (public@enkore.de) wrote:
> > ... while OpenSSH does support using a CA in conjunction with hostbased
> > authentication, it still requires a list of all authorized host names in the
> > rhosts / shosts file.
>
> I'm not familiar with the use of .rhosts/.shosts, but I don't think those are needed at all with a machine or per-user known_hosts file/files utilizing host certificates.
>
> The known_hosts file can have patterns such as the following:
>
> @cert-authority *.example.com ecdsa-sha2-nistp256 AAAAE2V...
>
> Would accept the host certificate authority for *.example.com. The "Hostnames" field can be expanded as needed, and can enclude hashed hostnames.
>
> See:
> https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Certificate-based_Authentication#4._Updating_Clients_to_Acknowledge_the_Designated_Certificate_Authority
>
> Another example (from the sshd man page)
>
> cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...
>
> Could that work for you?

AIUI what he is asking for is a file that combines the host identity
of the system-wide ssh_known_hosts file with the host/user authorisation
of shosts in a single file.

This might be a little cleaner, but IMO not so much so as to be highly
motivating (personally).

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 11/10/23 04:17, Damien Miller wrote:
> AIUI what he is asking for is a file that combines the host identity
> of the system-wide ssh_known_hosts file with the host/user authorisation
> of shosts in a single file.
>
> This might be a little cleaner, but IMO not so much so as to be highly
> motivating (personally).
>
> -d

Yup, but since this is auth code I imagine it would still require quite
some maintainer time to integrate a patch, if one were supplied. Plus
I'm under the impression that hostbased auth is somewhat of a
"discouraged" or at least arcane practice.

Cheers,
Marian

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, 11 Nov 2023, Marian Beermann wrote:

> On 11/10/23 04:17, Damien Miller wrote:
> > AIUI what he is asking for is a file that combines the host identity
> > of the system-wide ssh_known_hosts file with the host/user authorisation
> > of shosts in a single file.
> >
> > This might be a little cleaner, but IMO not so much so as to be highly
> > motivating (personally).
>
> Yup, but since this is auth code I imagine it would still require quite some
> maintainer time to integrate a patch, if one were supplied. Plus I'm under the
> impression that hostbased auth is somewhat of a "discouraged" or at least
> arcane practice.

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.

>
> Cheers,
> Marian
>
>
-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 11/15/23, 10:51 AM, "openssh-unix-dev on behalf of Marian Beermann" <openssh-unix-dev-bounces+iain.morgan=nasa.gov@mindrot.org <mailto:nasa.gov@mindrot.org> on behalf of public@enkore.de <mailto:public@enkore.de>> wrote:

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

Well, issuing user certs or leveraging AuthorizedKeysCommand can help in the case where pubkey authentication is used instead of hostbased. But, hostbased is generqally seen as more convenient in a cluster situation. I assume that you are aware of the shosts.equiv file, which can reduce the need for individual .shosts files.

As an aside, there doesn't seem to be any documentation in the man pages regarding the format of shosts.equiv, ~/.shosts, etc. I thought the man pages used to refer to rsh(1) or rlogin(1) for this, but I seem to be unable to find that. Since modern systems rarely have those installed, the ssh(1) or sshd(8) man pages should probably document the trivial format.

--
Iain

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev