On Mon, Oct 21, 2019, at 1:16 PM, James Ralston wrote:
On Sun, Oct 20, 2019 at 8:54 PM James Cassell fedoraproject@cyberpear.com wrote:
Even if local authentication works w/o the userCertificate attribute, SSH authentication using the Smart Card inherently requires the userCertificate attribute because the certificate is not sent over the SSH session.
When you say "SSH authentication using the Smart Card", what exactly do you mean?
I mean using the private key on the Smart Card as the SSH private key. SSSD will convert the userCertificate into SSH public keys for consumption by openssh.
If you mean being able to ssh to another host after one has logged in, we don't care about that, because we use gssapi-with-mic/gssapi-keyex authentication, which bypasses the PAM auth stack entirely.
A use case we would like to be able to make work is the ability for Windows users to ssh into Linux hosts. But we expect we will be unable to get that to work, because:
- There is no Windows SSH client implementation that we know of that
can both perform gssapi-with-mic/gssapi-keyex *and* delegate the Kerberos credentials. For example, PuTTY can do the former, but we've never been able to get it to do the latter, which means that if the user logs in from Windows using PuTTY, they will have no home directory, because we use autofs-mounted NFSv4 home directories with auth=krb5p. (No TGT, no home directory.)
PuTTY can do this ticket forwarding. The limiting factor is convincing the Active Directory team (or the security team) to enable the checkbox "Trust this computer for delegation to any service (Kerberos only)" -- there is also an adcli command line arg to set this option on Computer Account creation, but I've not tried setting it with adcli. I've gotten this working for the subset of machines for which InfoSec approved using the "Trust this computer for delegation to any service (Kerberos only)" checkbox.
(Side note: is there a good guide to setting up NFSv4 w/ auth=krb5p? I've been wanting to do this instead of forcing cifs/samba into its place... virtually every NFS guide I've found left things cleartext.)
- I have no idea if a Windows SSH client exists that can proxy the
smartcard protocol, as la p11-kit:
https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html
Yeah, I'd be interesting in something like that, as well.
Theoretically, I could write a (opensc?) plugin/driver that combines a forwarded ssh-agent with a userCertificate from AD/sssd and expose that as a Smart Card, but I'm not sure if that could run within the PAM session, or only afterwards... I briefly looked at using the initial SSH key verification to do a pkinit (without any agent forwarding), but it looks like its signature structure is too strict to leverage as a pkinit attempt.
nssdb is likely to be required for SSH Smart Card authentication
Again, I don't think we care about this.
There's a subtle bug in OpenSC that breaks CoolKey-based cards using 2048-bit RSA certificates (which is what we're using):
aha! Did you add the coolkey driver to the nssdb? That could be your issue.
No, I didn't, because I saw nothing in any documentation that stated this was necessary.
The easiest way I know to do that is to install the `opensc` package then:
# pkcs11-switch coolkey
opensc should be used instead of coolkey, as coolkey is deprecated in RHEL7, and has been removed from RHEL8 entirely.
Yes, I'm using opensc. I only referenced coolkey since you said your cards were coolkey-based.
I can't test in our production environment at the moment, but I have a test environment that is configured as close to our production environment as I can make it, and in our test environment:
$ pkcs11-switch; echo EOF
EOF
So, no, /etc/pki/nssdb is not configured to use a PKCS#11 module at all.
$ pkcs11-switch opensc; echo EOF
WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q <enter>' to abort, or <enter> to continue:
Module "OpenSC PKCS #11 Module" added to database. ERROR: Failed to delete module "CoolKey PKCS #11 Module". EOF
$ pkcs11-switch; echo EOF opensc EOF
And, lo and behold, in the test environment gdm now detects a smartcard insertion and prompts for the pin.
(In our test environment, PKINIT fails because our AD KDCs aren't properly configured for it, so I can't be sure this is the last hurdle until I replicate this to our production environment.)
I still can't get /usr/bin/login on a virtual console to correctly perform smartcard authentication, though. Have you managed to get that working?
I was also able to get this working at the console. I didn't do anything special for the console; it just worked once the GUI was working.
was it trivial to recompile [pkinit] w/ debug flags?
Yes. I've attached the two patches I created. Apply them against the latest upstream c7 branch:
$ git clone https://git.centos.org/git/rpms/krb5.git $ git clone https://git.centos.org/git/centos-git-common.git
…then mockbuild as usual.
WARNING: we found that installing the resulting krb5 packages with debugging enabled will *break* authentication. Only install the debugging packages locally while you are testing kinit, and "yum downgrade" back to the non-debugging packages immediately after you are done.
Thanks!
On Mon, Oct 21, 2019 at 5:39 AM Sumit Bose sbose@redhat.com wrote:
This [smartcard prompting] is a feature of GDM which requires the dconf setting as you mentioned before and that the PKCS#11 module (OpenSC or Coolkey) is added to /etc/pki/nssdb.
Yes, I realize that now. But this requirement is documented nowhere that I encountered it.
The latter should be done automatically during the installation of the related package.
No %post script on the system calls pkcs11-switch:
$ rpm -qa --scripts | grep pkcs11-switch
That includes opensc:
This is something I've always had to do manually, and I've always done it via:
# pkcs11-switch opensc
$ rpm -q --scripts opensc postinstall program: /sbin/ldconfig postuninstall program: /sbin/ldconfig
Not a single document I could find anywhere on gnome.org mentions this requirement, either.
If something was supposed to automatically perform this step for me, I don't know what it is.
About dconf, how did you add the Smartcard authentication option?
We maintain dconf settings via Puppet.
But as James Cassell noted, it's the default, anyway.
/etc/pki/nssdb on RHEL7 (or /etc/sssd/pki/sssd_auth_ca_db.pem on RHEL8) should contain the CA certificates needed to verify the user certificate.
Is this necessary for PKINIT authentication? Or just for SSH authentication?
SSSD can do Smart Card authentication without pkinit. To test it out, just remove the krb5-pkinit package. In that case, only the nssdb is consulted and pkinit_anchors is irrelevant.
I'm not sure whether SSSD does its own Smart Card authentication prior to attempting pkinit, but it wouldn't surprise me as before I'd gotten pkinit working via the timeout tweaks, I'd still be allowed to logon after the pkinit attempts timed out (after 5 tries, I think is what sssd was doing internally.)
We would like to avoid having to do this, because update-ca-trust(8) does not maintain /etc/pki/nssdb, which means we will have to come up with a mechanism to maintain /etc/pki/nssdb automatically on our hosts.
(If we can't automate it, we don't do it.)
I'm in a similar situation... hoping to not write my own nssdb ansible role, but I'll probably need to write one since I didn't see a good existing one.
I commented in the pagure ticket and mentioned a work-around.
I saw; thanks. I'll respond in the ticket.
Thank you both for helping to improve the documentation about Smartcard authentication with real-world examples.
You're welcome.
With the rise of multi-factor authentication (MFA) solutions like Google Authenticator and Duo, using smartcards for MFA is clearly on the decline. (And it was never that popular to begin with.)
But, alas, there are some environments where smartcard MFA is mandated. So hopefully documenting how to get this to work will be useful to others.
It's certainly not going away anytime soon for companies who have government, and especially DoD, contracts.
V/r, James Cassell