Bug 5187 - Support smartcards without configured PINs
Summary: Support smartcards without configured PINs
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Smart card (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Pierre Ossman
Depends on:
Reported: 2014-06-11 08:32 CEST by Aaron Sowry
Modified: 2014-10-15 14:54 CEST (History)
0 users

See Also:
Acceptance Criteria:


Description Aaron Sowry cendio 2014-06-11 08:32:35 CEST
Pinless authentication is a valid use-case according to the relevant specifications, however OpenSC does not currently have support for doing so. We should add support for this in OpenSC.
Comment 1 Peter Åstrand cendio 2014-10-15 14:47:10 CEST
For Sun Ray conversion cases, removing the PIN is perhaps not the preferred method. Instead, we could consider a case when the smart card insertion triggers the login, not with smart card public key authentication, but with, for example "auth none", ie no required authentication at all. This should correspond to the Sun Ray case where the card serial number is sufficient. 

Currently, it is only possible to trigger automatic connection upon smart card insertion if you also activate the option for using the certificate subject name as user name. Also, passwdaliases only works with public key authentication: It does not work with password (or "none") authentication. This, in turn, means that you must actually create "real" users of the form:

serialNumber=197703012570,givenName=Peter Alf G\c3\b6ran,sn=\c3\85strand,cn=Peter \c3\85strand,c=SE

If you combine this with the sshd_config option PermitEmptyPasswords, it is actually possible to login "Sun Ray style", ie without entering a PIN code, even though there's a PIN on the card. The drawback is that you have to manually maintain users in /etc/passwd. Also, the "USER" environment variable etc will be this very long subject name, which causes problems with some software. On my CentOS 6 machine, XFCE works fine, but GNOME fails to start and instead hogs all memory it can find. gconfd took 16 GiB before I managed to kill it...

So, I guess in order to use this in practice, I think we need to make passwdaliases work with "auth none" and passwords. One idea is to investigate if it's possible to write a PAM module which takes care of the translation.
Comment 2 Peter Åstrand cendio 2014-10-15 14:54:45 CEST
I've found a way to avoid that the certificate subject name ends up in USER: Add both the normal and the certificate subject to passwd, using the same uid. For example:

serialNumber=197703012570,givenName=Peter Alf G\c3\b6ran,sn=\c3\85strand,cn=Peter \c3\85strand,c=SE:x:4041:4041::/local/home/astrand4:/bin/bash

shadow should only have the long name:

serialNumber=197703012570,givenName=Peter Alf G\c3\b6ran,sn=\c3\85strand,cn=Peter \c3\85strand,c=SE::16358:0:99999:7:::

This solution seems to work fine.

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