On Mon, Oct 21, 2019, at 1:16 PM, James Ralston wrote:
On Sun, Oct 20, 2019 at 8:54 PM James Cassell
<fedoraproject(a)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:
1) 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.)
2) 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(a)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