Bug 1654830 - [RFE] sshd_config option to export export principal which was used for .k5login
Summary: [RFE] sshd_config option to export export principal which was used for .k5login
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: openssh
Version: 8.0
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 8.1
Assignee: Jakub Jelen
QA Contact: BaseOS QE Security Team
Depends On: 1658642 1682500
TreeView+ depends on / blocked
Reported: 2018-11-29 19:12 UTC by Pat Riehecky
Modified: 2021-01-06 18:13 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1409351
Last Closed:
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenSSH Project 2063 0 None None None 2019-08-05 11:40:08 UTC

Description Pat Riehecky 2018-11-29 19:12:33 UTC
+++ This bug was initially created as a clone of Bug #1409351 +++

Business Justification:
It would be nice to have information which principal was used for log in 
via .k5login.   Tools such as gitolite utilize the identity information provided by the login to further delegate specific rights.

Technical requirements:
Can a sshd_config option to export export principal which was used for .k5login be added?

Other information:
Upstream bug report with a few viable patches: https://bugzilla.mindrot.org/show_bug.cgi?id=2063  In particular comment#2 and the associated patch look to be exactly what should work here.

--- Additional comment from Jakub Jelen on 2017-01-02 04:02:32 EST ---

The patch looks good, but I would rather see it accepted upstream before adding another downstream patch to RHEL7.

--- Additional comment from Pat Riehecky on 2017-02-14 11:29:14 EST ---

It doesn't look like anyone upstream is assigned to shepherd the patch into the tree.

Comment 1 Jakub Jelen 2018-12-04 13:51:07 UTC
This bug should be resolved by using the following configuration in the server:

> ExposeAuthInfo
>     Writes a temporary file containing a list of authentication methods and
>     public credentials (e.g. keys) used to authenticate the user.  The
>     location of the file is exposed to the user session through the
>     SSH_USER_AUTH environment variable.  The default is no.

If I see right, this already records the the displayname for most of the authentication methods (the only issue I can think of might be the gssapi-kex authentication method, which is not upstream).

Can you check if this solution works for you?

I will make sure the results are consistent also with the gssapi-kex authentication method.

Comment 2 Pat Riehecky 2018-12-04 14:59:48 UTC
This loosely solves the issue.  However, I'm a bit worried about the file IO cost and the pollution of /tmp/ with files.

Would it be better to put the $SSH_USER_AUTH file under /run/user/$EUID/sshd_auth/ ?  That wouldn't write out so many little files to disk and will keep them isolated.

Comment 3 Jakub Jelen 2018-12-04 15:33:16 UTC
Well ... that is more upstream developers decision where the files are stored (the /run/user/ is probably not yet portable enough for them).

I would not be worried with the IO cost on tmpfs (The key exchange itself is much more expensive for the network communication and computation power, the authentication itself already touches a lot of other files around -- passwd, authorized keys ...), but the real-world problem might be full /tmp/, which would prevent creation of this file and breaking applications that might depend on that.

On the other hand, storing the file in specific place under /run/user/ might overwrite some of the previous authentications, that could have used some different authentication methods that is indeed not wanted.

Checking a bit further, there is also environment variable SSH_AUTH_INFO_0, which is exposed to PAM regardless the above option and basically contains the same thing as the file. Extracting that through some PAM module to the session itself is kind of hacky, but might do the job.

It looks like there are more people who would like to see this a bit different. Feel free to follow up on this on upstream bug which brought this over the last years:


Comment 4 Pat Riehecky 2018-12-04 15:49:58 UTC
The upstream bug is very interesting.  I'll have to look into SSH_AUTH_INFO_0 a bit more.

Would RHEL be willing to carry a patch to move the the authinfo file into /run/?  I've got a system that loads of folks use for login and I'd rather not wear out the SSD I've got mounted on /tmp/.

You're right, a full /tmp/ would be an issue there....

session.c has a hardcoded path name:

        auth_info_file = xstrdup("/tmp/sshauth.XXXXXXXXXXXXXXX");

Example psudo code that doesn't actually work as it drops priv so it can't mkdir:
--- session.c.orig	2018-12-04 09:39:30.798410320 -0600
+++ session.c	2018-12-04 09:44:54.587391137 -0600
@@ -273,7 +273,8 @@ prepare_auth_info_file(struct passwd *pw
+       mkdir("/run/sshauth", 0777)
+	auth_info_file = xstrdup("/tmp/sshauth/XXXXXXXXXXXXXXX");
-	auth_info_file = xstrdup("/tmp/sshauth.XXXXXXXXXXXXXXX");
 	if ((fd = mkstemp(auth_info_file)) == -1) {
 		error("%s: mkstemp: %s", __func__, strerror(errno));
 		goto out;

Functionally the filename is supposed to be non-deterministic.

Comment 5 Jakub Jelen 2018-12-12 15:16:10 UTC
I would like to start using the /run/ for these runtime stuff if possible, but the upstream acceptance of everything that contains systemd is very cold, but we should try first. There is getting more things like that and openssh should claim the ssh directory under /run/user/UID/. Most of the tools have uniquely named sockets, but for example gnupg creates some tmp directories in there so I do not think this should be an issue.

Once implementing this, we should do it in all the following places:
 * The location of file with information about authentication
 * The default location of the ssh-agent socket (in Gnome, gnome-keyring is already taking the socket here)
 * The default location of the forwarded kerberos credential cache
 * The location of the forwarded ssh-agent socket

I can not think of any other thing that OpenSSH could use this directory for.

I will certainly have a look into that and keep you updated. But I will probably open a new bug for this since it is getting out of the scope of the original request.

Note You need to log in before you can comment on or make changes to this bug.