Agent Smart Card Reader V.2.0 Download
Jeri Findley
If the image builder that you want to connect to is joined to an Active Directory domain and your organization requires smart card sign in, you must create a streaming URL and use the AppStream 2.0 client for the connection. For information about smart card sign in, see Smart Cards.
In other cases, USB devices are already enabled for use with AppStream 2.0 and no further configuration is required. For example, smart card redirection is already enabled by default when the AppStream 2.0 client is installed. Because USB redirection isn't used when this feature is enabled, you don't need to qualify smart card readers, and users don't need to share these devices with AppStream 2.0 to use them during streaming sessions.
AppStream 2.0 supports using a smart card for Windows sign in to Active Directory-joined streaming instances and in-session authentication for streaming applications. Because smart card redirection is enabled by default, users can use smart card readers that are connected to their local computer and their smart cards without USB redirection.
AppStream 2.0 supports the use of Active Directory domain passwords or smart cards such as Common Access Card (CAC) and Personal Identity Verification (PIV) smart cards for Windows sign in to AppStream 2.0 streaming instances (fleets and image builders). Your users can use smart card readers connected to their local computer and their smart cards to sign in to an AppStream 2.0 streaming instance that is joined to a Microsoft Active Directory domain. They can also use their local smart card readers and smart cards to sign in to applications within their streaming session.
By default, password sign in for Active Directory is enabled on AppStream 2.0 stacks. You can enable smart card sign in for Active Directory by performing the following steps in the AppStream 2.0 console.
You can disable smart card redirection during client installation on managed devices. For more information, see Choose Whether to Disable Smart Card Redirection. If you disable smart card redirection, your users can't use their smart card reader and smart card during an AppStream 2.0 streaming session without USB redirection. In this case, you must qualify the device. After you qualify the device, users must share the device with AppStream 2.0. When smart card redirection is disabled, during users' AppStream 2.0 streaming sessions, their smart card reader and smart card are not accessible for use with local applications.
I decided the best course of action was to obtain some OpenPGP smart cards and USB readers, and start afresh with a brand new key. The cards will help me keep the key secure while at the same time being able to use it on a number of machines, even less trusted machines, without risk of it being compromised. Because I only have a small number of signatures on my old key, it would be best to create a new key before I get many more signatures.
Now is probably a good time to ensure the PIN codes on the card are changed to sensible values. Note that despite these being called PIN codes, the cards will accept full ASCII passwords, and not just numbers. You may, however, want to restrict yourself to just numbers if you want to use a pin-pad reader for Secure PIN Entry, as they usually only have numeric buttons on them.
I chose to use two smart cards; if you only want to use one, skip moving the primary key and only move across the sub-keys. You can simply mount your LUKS-encrypted volume on the rare occasions you need to use your primary key.
I would like to be able to have two or more GnuPG cards inserted at the same
time, and have gnupg/gpg-agent/scdaemon notice all of them and use whichever one
was appropriate for the operation at hand, without my having to switch them in
and out.
I do have multiple readers. If I insert one card in each of my two readers, GnuPG doesn't choose the one it needs for any given operation. It's been three years, so I don't remember exactly what DOES happen. I think it just acts as if one of the two cards were inserted, and totally ignores the existence of the other. What I want is for it to dynamically use keys from whatever cards happen to be inserted.
For your information.
Since 2.1.18, multiple readers are supported by internal CCID driver. PC/SC driver is not yet.
Since 2.1.20, gpg --card-status can have "all" or specific serialno of the card.
Perhaps, gpg --card-edit should support SERIALNO command as well.
After turning on the scdaemon debug log and comparing the "xyz reader detected" messages, I found the issue: The pcscd daemon was running by default and claiming the card readers. scdaemon will issue a harmless looking "ccid open error: skip" message in the logfile with gnupg 2.2.4. It then falls back to the pcsc driver.
I found if I have both plugged in, it sees the one it detected first, making the keys on the second inaccessible. I'm pretty new to CCID smartcard interfaces, having just relied on keeping the private key on my workstation's hard drive in the past.
I checked the ./configure options, and it does appear that smartcard support is being enabled. I also verified permissions on the /dev/hidraw* devices; they were owned by the plugdev group and my user is a member of that group.
Even running gpg as root didn't help, it would not see the smartcard. I couldn't see anything obviously wrong, scdaemon was running (and it was the correct version; even tried rebooting the machine to make sure of that), but it would not see even one YubiKey plugged in.
I am using the OpenPGP card to authenticate with my SSH server. If I use them in isolation everything works great. But if I have both of those smart card readers connected then the agent only finds the VPN key, which is refused by the SSH server.
Only if I manually through the device manager temporarily disable the Virtual Smartcard, which as far as I can tell is a whole virtual reader, then the agent finds 2 keys, and one of them is accepted from the SSH server. See screenshots in this downstream bug report: [3]
Some more info: OpenVPN does not care about the second reader only gnupg agent is sensitive to what is present when it is started. So a workaround that I just found is to disable the Virtual Smartcard reader first so that only the ReinerSCT smartcard reader with an OpenPGP V3.4 card is present. Make sure to open an SSH connection. Then reconnect the second reader. And reconnect to VPN. After the PIN for the OpenPGP V3.4 card is already cached and a connection to the card established I can also open more SSH connections with the second reader attached and disconnect and reconnect the VPN as I want.
Even removing the smartcard from the ReinerSCT reader and plugging it back in works and I can still authenticate with new SSH tunnels and both readers present. So it seems it is actually only important which readers are present when the agent connects for the first time.
So this is a practical woraround. Although disabling the TPM backed reader temporarily needs Admin rights and is really janky.
The other ones don't even work with the TPM smartcard not present. The Omnikey 3621 works if I install the driver from the vendor but not with the built-in keypad. Same with the ACS ACR83, which also works but the built-in keypad doesn't.
The SCM SPR532 works on my desktop computer, but fails after inputting the PIN on my laptop with Pageant failed to provide a signature. And yes I have tried installing drivers from vendor page, updating OpenSC, and updating pgp-agent and the win-gpg-agent wrapper. The readers are recognized and work with other software but not with gpg-agent.
Specify true to permit smart card logon as an alternative to Duo authentication after successful submission of primary credential. If a PIV card reader with the smart card of the authenticating user is attached to the system then the Duo Prompt is not shown. Specify false to disable smart card logon and require Duo 2FA. Defaults to false. Do not enable this for Duo versions prior to 2.0.0.
The configuration script creates a new deployment package with the values you specify. For example, this command configures the Duo for macOS installation package located in the same directory as the configuration script, with fail open enabled, smart card login disabled, and automatic push enabled, and then creates the deploy package MacLogon-2.0.2.pkg:
Enable or disable two-factor authentication for a user when they log in with a smart card post-installation with the following syntax, specifying true to skip 2FA after smart card for primary credentials or false to require 2FA after smart card login:
Now I will generate three keys that will go onto the smartcard. I have chosen to generate these using GnuPG and then move the keys onto the smartcards, instead of generating the keys directly on the card. The difference is that with this approach, I get a backup of the keys and can import them to another key in the future if I need to.
This was incredibly helpful, thanks! One thing I ran into was with Ubuntu 16.04 I had to enable the universe repository. I also was wishing for pcsc-tools to scan for and select a specific smartcard reader since my laptop has one built in as well.
The final hurdle I ran into was a weird error from gpg after uploading a signing key that there was an error on writing the encryption and authentication keys. I was able to get around this by using gpg2 to do the write, but I had to restart the gpg-agent (actually just pulled and reinserted the card) in order to allow gpg2 to access it since gpg1 had a lock on it.
The most common reason for GPG not to see the YubiKey is that there are multiple SmartCard readers in the system. This is caused by the fact that if there is more than one SmartCard reader in the system, scdaemon just defaults to checking the first one and if that is not a GPG compatible smart card (in our case the YubiKey), it does not try the other ones.
I am attempting to ssh onto a CentOS 7.5 machine (192.168.1.5) via smart card technology.
Now I can SSH using the master slot's x509 certificate with the matching private key to accomplish this, but this means that I must put the certificate's public key onto every machine that I wish to SSH onto. That is tedious if you ask me.
Therefore I want to use a different public/private, specifically RSA keys, so that I can, at some time in the future, sign them with an RSA Certificate allowing for OpenSSH to trust the RSA Certificate and prevent the need to trust every single smart card's x509 Certificate. But for now I just want to SSH with this RSA key pair from the smart card.