openssh unix dev - Oct 2019 - authorized_principals for Kerberos authentication

Hello,

SSH supports ~/.ssh/authorzied_keys for SSH keys and
~/.ssh/authorized_principals for X509 certs.

I could not find an equivalent of authorzied_keys
using Kerberos authentication.

IMHO it should be possible using the Kerberos principal
very much like the principal contained inside a X509
certificate.

My main use case is assigning a specific command to
a user logging in using Kerberos credentials instead
of an SSH hey.

Before I try and implement a patch, I wanted to ask if
such a solution has been discussed before. Is there
a technical or security related reason that might
prohibit such an implementation?


Best regards
Friedrich Sch?uffelhut

On Fri, 4 Oct 2019, Friedrich Schaeuffelhut wrote:
> Hello,
> 
> SSH supports ~/.ssh/authorzied_keys for SSH keys and
> ~/.ssh/authorized_principals for X509 certs.
> 
> I could not find an equivalent of authorzied_keys
> using Kerberos authentication.
I think you want ~/.k5login, but it's been years since I've used
kerberos.

https://web.mit.edu/kerberos/krb5-devel/doc/user/user_config/k5login.html

-d

On 10/5/2019 3:26 AM, Damien Miller wrote:
> On Fri, 4 Oct 2019, Friedrich Schaeuffelhut wrote:
> 
>> SSH supports ~/.ssh/authorzied_keys for SSH keys and
>> ~/.ssh/authorized_principals for X509 certs.
>>
>> I could not find an equivalent of authorzied_keys
>> using Kerberos authentication.
> 
> I think you want ~/.k5login, but it's been years since I've used
> kerberos.
Looking at the current portable code, it appears to just call 
krb5_kuserok(). That may look at k5login (the location of which is 
configurable), krb5_aname_to_localname(), a custom method, or multiple 
of the above, depending on which kerberos library is in use and how it 
is configured. (Note that Red Hat has muddied the waters with their 
patches, but let's ignore that).

To support the OP's ask of ForceCommand, etc., OpenSSH would need to 
either support exposing the client principal as a type which can be used 
in a Match block, or add Yet Another authorized_foo file (or extend the 
format of an existing one).

I think exposing the authorized_foo functionality via Match operators 
would be a more elegant solution, but I don't know how difficult that 
would be to code, as I haven't looked at when (and in which process) 
they are evaluated.

-- 
Carson