Bug 1326

Summary:	Allow non-public-key credentials in authorized_keys file (Kerberos, etc.)
Product:	Portable OpenSSH	Reporter:	Markus Kuhn <Markus.Kuhn>
Component:	Kerberos support	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	REOPENED ---
Severity:	enhancement	CC:	dtucker, matthew.nygard.dodd
Priority:	P2
Version:	4.4p1
Hardware:	All
OS:	Linux
See Also:	https://bugzilla.mindrot.org/show_bug.cgi?id=1927

Description Markus Kuhn 2007-06-29 07:12:36 AEST

At present, the ~/.ssh/authorized_keys file serves two functions:

  - list RSA or DSA keys that are authorized as login credentials

  - define policy restrictions (command=, from=, etc.) for each

Unfortunately, all the wonderful policy restrictions that authorized_keys allows are currently only available for public-key authentication. It would be extremely useful, if authorized_keys supported also other authentication methods supported by ssh, not just just ssh-rsa and ssh-dsa, such that these can also be restricted with policy options such as command, from, etc.

Most importantly, it should be possible to name and restrict a GSSAPI/Kerberos principal in an authorized_keys file. Example:

from="*.bla.com" ssh-rsa AAAAB3NzaC1yc2EAAAA....
from="*.bla.com" ssh-gssapi johndoe@bla.com
from="*.bla.com" ssh-md5password fa45c39ad35d1efa635916459dac4bed
command="/bin/helpdesk" ssh-md5password 163fa56fade48646fa4562ecb6b7901

The authorized_keys file could even be renamed to authorized_credentials, to reflect that it is a list of credentials that are authorized for login, which includes, but is not restricted to, RSA and DSA keys.

For Kerberos logins, the extended syntax of the authorized_keys file that I propose would allow me to list authorized Kerberos principals whose name is not identical to the local user name, just like there is with RSA or DSA no need that the login names are identical on the ssh client and server side.

Comment 1 Darren Tucker 2007-06-29 08:06:50 AEST

(In reply to comment #0)
> At present, the ~/.ssh/authorized_keys file serves two functions:
> 
>   - list RSA or DSA keys that are authorized as login credentials
> 
>   - define policy restrictions (command=, from=, etc.) for each
> 
> Unfortunately, all the wonderful policy restrictions that
> authorized_keys allows are currently only available for public-key
> authentication.

Actually that's no longer the case.  In the most recent versions, the policy restrictions also available in sshd_config via Match, ForceCommand, PermitOpen and so on.

You can implement some parts of your example with those, for example:

Match User gssapiuser Host *.blah.com
    GSSAPIAuthentication yes
    PasswordAuthentication yes
    ForceCommand /bin/helpdesk
Hatch User gssapiuser
    GSSAPIAuthentication no
    PasswordAuthentication no
    ForceCommand /bin/helpdesk

would allow the user "gssapiuser" to authenticate using gssapi or password only from machines in the blah.com domain, and only allow them to run the /bin/helpdesk program no matter how they authenticated.

Comment 2 Darren Tucker 2010-01-13 11:24:14 AEDT

I think the Match capability provides the requested functionality, so I'm closing.  Thanks for the suggestion, but I don't think we'll be doing this.

Comment 3 Damien Miller 2010-04-16 15:50:43 AEST

Mass move of bugs RESOLVED->CLOSED following the release of openssh-5.5p1

Comment 4 Markus Kuhn 2010-04-16 20:41:02 AEST

But the Match capability of /etc/ssh/sshd_config is only accessible to the system administrator, and there seems nothing equivalent that the user can do themselves in ~/.ssh/.