Bug 1654830
Summary: | [RFE] sshd_config option to export export principal which was used for .k5login | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Pat Riehecky <riehecky> |
Component: | openssh | Assignee: | Dmitry Belyavskiy <dbelyavs> |
Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 8.0 | CC: | cparadka, cww, dpal, jjelen, lav, mkosek, qe-baseos-security, rharwood, riehecky, sbose, szidek, vmishra |
Target Milestone: | rc | Keywords: | FutureFeature, Patch, Triaged, WorkAround |
Target Release: | 8.1 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1409351 | Environment: | |
Last Closed: | 2021-05-04 13:41:01 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1658642, 1682500 | ||
Bug Blocks: |
Description
Pat Riehecky
2018-11-29 19:12:33 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.
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. 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: https://bugzilla.mindrot.org/show_bug.cgi?id=2408 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 return; temporarily_use_uid(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. 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. I think we agreed that the SSH_AUTH_INFO_0 should address this issue. Can we close the bug now? I believe this can be closed out. |