smartcard support is not enabled in openssh

It is not possible to use an usb token to store keys because openssh is not
compiled with opensc support.

To enable the smartcard support it is necessary to
 * get the sources with apt-get source openssh
 * modify debian/rules to add --with-opensc at the end of ./configure... lines
 * rebuild the package with dpkg-buildpackage

Right. The reason this hasn't been done yet is because I've been concerned about
pulling so many extra library dependencies into such a frequently installed package.

And if the smartcard support was enabled, it would add at least an other
dependency with opensc !
Maybe it would be better to create openssh-smartcard-* packages instead of
overbloating the existing ones with additional dependencies ?

But I don't know what is the best way from a maintainer point of view...

Message-Id: <20040206202243.707AD5CAFF4@nightcrawler>
Date: Fri, 06 Feb 2004 15:22:43 -0500
From: Eric Dorland <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: please include opensc support

Package: ssh
Version: 1:3.6.1p2-11
Severity: wishlist

I've recently uploaded the opensc package to unstable. It contains
infrastructure for supporting smart cards and usb tokens. OpenSSH can be
compiled with opensc support (see ./configure --help, --with-opensc
switch). It would be great to be able to incorporate the opensc support
into openssh. I'm eager to send you a patch for enable this support, but
I'm not sure how you would like to go about it. If it was enabled in the
current openssh package, I would need to put opensc in standard which
may not be popular (although if smart card usage takes off this move may
make sense). Or would you prefer to have a seperate package (ssh-sc or
something) that is contains the opensc enabled ssh?

Eagerly awaiting your reponse :)

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.0
Locale: LANG=en_US, LC_CTYPE=en_US

Versions of packages ssh depends on:
ii adduser 3.51 Add and remove users and groups
ii debconf 1.4.8 Debian configuration management sy
ii dpkg 1.10.18 Package maintenance system for Deb
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii libpam-modules 0.76-15 Pluggable Authentication Modules f
ii libpam-runtime 0.76-15 Runtime support for the PAM librar
ii libpam0g 0.76-15 Pluggable Authentication Modules l
ii libssl0.9.7 0.9.7c-5 SSL shared libraries
ii libwrap0 7.6-ipv6.1-3 Wietse Venema's TCP wrappers libra
ii zlib1g 1:1.2.1-3 compression library - runtime

-- debconf information excluded

Message-Id: <20040309053510.00753198CC7@nightcrawler>
Date: Tue, 9 Mar 2004 00:35:10 -0500
From: Eric Dorland <email address hidden>
To: <email address hidden>
Subject: cloning 231472, reassign -1 to ssh-krb5

# Automatically generated email from bts, devscripts version 2.7.95.1
clone 231472 -1
reassign -1 ssh-krb5

Message-ID: <email address hidden>
Date: Thu, 25 Mar 2004 18:56:47 +0000
From: Colin Watson <email address hidden>
To: Alessandro Razeto <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#240077: ssh: why not to compile with opensc?

tags 240077 - experimental sid
merge 231472 240077
thanks

On Thu, Mar 25, 2004 at 07:02:41PM +0100, Alessandro Razeto wrote:
> Package: ssh
> Version: 1:3.8p1-2
> Severity: wishlist
> Tags: experimental sid
>
> I think it could be usefull to compile ssh with opensc support, which
> is already included in the source files.
> One need only to add to debian/rules the --opensc=/usr directive to
> configure and add the source dependancy to libopensc0-dev.

Wouldn't that produce a binary package that depends on libopensc0,
thereby requiring everyone with ssh to install that library? It would
have to be a separate package, and I have concerns about the
maintainability of that approach.

Please search for existing bugs before filing new ones, by the way;
searching for "opensc" in ssh's bug page immediately finds #231472.

Cheers,

--
Colin Watson [<email address hidden>]

Message-Id: <1080252636.2543.18.camel@simulacron>
Date: Thu, 25 Mar 2004 23:10:37 +0100
From: Andreas Jellinghaus <email address hidden>
To: Colin Watson <email address hidden>, <email address hidden>
Cc: Alessandro Razeto <email address hidden>, <email address hidden>
Subject: Re: Bug#240077: ssh: why not to compile with opensc?

> Wouldn't that produce a binary package that depends on libopensc0,
> thereby requiring everyone with ssh to install that library?

yes, and opensc is compiled to use either openct or pcsc-lite
(has a library package, too) or both. and opensc is usualy linked
against openssl.

so yes, the result might be considered big and fat.

in comparison, microsoft has it's crypto api with the
cryptografic service provider, which is a nice design.
step by step the unix collection of grown libraries
is improved towards a similar architecture.

the whole situation is made worse by the fact, there
are many different projects implementing a similiar
set of functions, for example the many crypto libraries
out there, or openssl, gnutls and other library offering
tls (libnss is there at least, maybe others?).

and there is the plan of every project to support everything,
for example opensc not only supports pcsc-lite so ifdhandler
format drivers can be used, it also has build in support for
ct-api format drivers, it had for a while an internal framework
for usb tokens, which was replaced by the new openct driver
and middleware that opensc supports, too.

also while opensc currently uses openssl (but can be compiled
without at reduced functionality), there are aims to be able
to use gnutls as well, but to my knowledge gnutls has a long
way to go for offering the same features that openssl has.
and opensc not only uses openssl, but also has two libraries,
so called engines, that openssl can use to access smart
cards.

and don't forget nss, which cannot be used by opensc so far,
but nss can use any library implementing the pkcs#11 interface,
and opensc is implementing that.

if all that double and tripple functionality isn't enough,
opensc supports quite a number of smart cards, and is
gaining support for new ones step by step. each smart
card (operating system) is incompatible to each other,
so these (opensc internal) drivers are necesssary.

confused? I'm sorry. Let's go back to openssh.

While it would be utterly cool to have opensc support
in debian, I already expectet that you don't want it,
because of the many libraries.

But could you create a second package with opensc support
and maintain both? the differences are:
 - one configure flage: --with-opensc
 - one build dependency in the control: libopensc-dev
   (which results in several build and runtime library
   dependencies)
 - one patch (for ssh to ask for the pin openssh needs
   a redesign of some part, which markus (openssh developer)
   didn't find time so far to do. out patch is not that ugly,
   but not the clean design they like to have either. it does
   not touch anything outside the smart card related code.)

everything else is the same, not even changes in documentation,
config files, or debconf questions or anything. so three
simple changes, that's why it might be easier for...

Message-ID: <email address hidden>
Date: Mon, 3 May 2004 00:12:03 -0400
From: Eric Dorland <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: patch to build a ssh-opensc package

--gmhhrsDozM2n+uz5
Content-Type: multipart/mixed; boundary="UlsYxwg8UDQn+EKZ"
Content-Disposition: inline

--UlsYxwg8UDQn+EKZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

tags 240077 patch
tags 231472 patch
thanks

And here's the patch. I basically kept the same rules file and just
added some makefile magic to make it compile box versions of the
packages. Let me know what you think/any problems.

--=20
Eric Dorland <email address hidden>
ICQ: #61138586, Jabber: <email address hidden>
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+=20
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+=20
G e h! r- y+=20
------END GEEK CODE BLOCK------

--UlsYxwg8UDQn+EKZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ssh-opensc.diff"
Content-Transfer-Encoding: quoted-printable

diff -ruN openssh-3.8p1/debian/control openssh-3.8p1.new/debian/control
--- openssh-3.8p1/debian/control 2004-05-02 23:43:35.000000000 -0400
+++ openssh-3.8p1.new/debian/control 2004-05-02 23:46:57.000000000 -0400
@@ -2,14 +2,15 @@
 Section: net
 Priority: standard
 Maintainer: Matthew Vernon <email address hidden>
-Build-Depends: libwrap0-dev | libwrap-dev, zlib1g-dev | libz-dev, libssl-d=
ev, libpam0g-dev | libpam-dev, libgnomeui-dev (>=3D 2.0.0) | libgnome-dev, =
groff, debhelper (>=3D1.1.17), sharutils
+Build-Depends: libwrap0-dev | libwrap-dev, zlib1g-dev | libz-dev, libssl-d=
ev, libpam0g-dev | libpam-dev, libgnomeui-dev (>=3D 2.0.0) | libgnome-dev, =
groff, debhelper (>=3D1.1.17), sharutils, libopensc0-dev
 Standards-Version: 3.6.1
 Uploaders: Colin Watson <email address hidden>
=20
 Package: ssh
 Architecture: any
 Depends: ${shlibs:Depends}, ${debconf-depends}, ${pam-depends}, libpam-mod=
ules (>=3D 0.72-9), adduser (>=3D 3.9), dpkg (>=3D 1.9.0)
-Conflicts: ssh-nonfree (<<2), ssh-socks, ssh2, sftp, rsh-client (<<0.16.1-=
1)
+Conflicts: ssh-opensc, ssh-nonfree (<<2), ssh-socks, ssh2, sftp, rsh-clien=
t (<<0.16.1-1)
+Replaces: ssh-opensc
 Suggests: ssh-askpass, xbase-clients, dnsutils
 Provides: rsh-client
 Description: Secure rlogin/rsh/rcp replacement (OpenSSH)
@@ -32,6 +33,35 @@
  In some countries it may be illegal to use any encryption at all
  without a special permit.
=20
+Package: ssh-opensc
+Architecture: any
+Priority: extra
+Depends: ${shlibs:Depends}, ${debconf-depends}, ${pam-depends}, libpam-mod=
ules (>=3D 0.72-9), adduser (>=3D 3.9), dpkg (>=3D 1.9.0)
+Conflicts: ssh, ssh-nonfree (<<2), ssh-socks, ssh2, sftp, rsh-client (<<0.=
16.1-1)
+Replaces: ssh
+Suggests: ssh-askpass, xbase-clients, dnsutils
+Provides: ssh, rsh-client
+Description: Secure rlogin/rsh/rcp replacement (OpenSSH with OpenSC suppor=
t)
+ This is the portable version of OpenSSH, a free implementation of
+ the Secu...

Message-ID: <email address hidden>
Date: Mon, 3 May 2004 09:17:28 +0100
From: Colin Watson <email address hidden>
To: Eric Dorland <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#240077: patch to build a ssh-opensc package

On Mon, May 03, 2004 at 12:12:03AM -0400, Eric Dorland wrote:
> And here's the patch. I basically kept the same rules file and just
> added some makefile magic to make it compile box versions of the
> packages. Let me know what you think/any problems.

It's unlikely to apply very well the first time when this can be looked
at, i.e. after sarge, since the client and server will be split out
then.

I have a general objection, though: consider N features in OpenSSH which
require extra libraries (there are a few filed as other bugs, IIRC). How
many packages am I supposed to build? N? 2^N? Dealing with configuration
files would be a total nightmare. And so on. As I said in my original
mail to you, "It would have to be a separate package, and I have
concerns about the maintainability of that approach."

I'd rather wait until we split out client and server, then build the
server with some extra features by default since the server will be in
optional rather than standard.

Thanks,

--
Colin Watson [<email address hidden>]

Message-ID: <email address hidden>
Date: Mon, 3 May 2004 20:56:21 -0400
From: Eric Dorland <email address hidden>
To: Colin Watson <email address hidden>
Cc: Eric Dorland <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: Bug#240077: patch to build a ssh-opensc package

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Colin Watson (<email address hidden>) wrote:
> On Mon, May 03, 2004 at 12:12:03AM -0400, Eric Dorland wrote:
> > And here's the patch. I basically kept the same rules file and just
> > added some makefile magic to make it compile box versions of the
> > packages. Let me know what you think/any problems.
>=20
> It's unlikely to apply very well the first time when this can be looked
> at, i.e. after sarge, since the client and server will be split out
> then.

No problem, I can redo the patch then, but lets keep it around for
reference.=20

> I have a general objection, though: consider N features in OpenSSH which
> require extra libraries (there are a few filed as other bugs, IIRC). How
> many packages am I supposed to build? N? 2^N? Dealing with configuration
> files would be a total nightmare. And so on. As I said in my original
> mail to you, "It would have to be a separate package, and I have
> concerns about the maintainability of that approach."

I understand that point of view, but I also would love to see this
functionality in ssh (and I'm sure others have features they'd like to
see). Would you be amenable to doing something similar to the exim4
maintainers -heavy and -light packages? This way you only need C=3D2
packages :)

I'm not sure what you mean by dealing with the configuration files,
but I don't think the opensc support adds any addition configuration
options...
=20
> I'd rather wait until we split out client and server, then build the
> server with some extra features by default since the server will be in
> optional rather than standard.

Well the opensc library would affect the client, not the server
(actually it may be used on the server as well, I'm not sure...), so
it wouldn't be used in the server.=20

--=20
Eric Dorland <email address hidden>
ICQ: #61138586, Jabber: <email address hidden>
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+=20
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+=20
G e h! r- y+=20
------END GEEK CODE BLOCK------

--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAluo0YemOzxbZcMYRApbXAKCjwb7rJ9jwuk5ougmSkp8qvsp0IQCffy8J
OkyoGQfP+fA5n5Jbkcgw4yE=
=do8r
-----END PGP SIGNATURE-----

--a8Wt8u1KmwUX3Y2C--

Message-Id: <email address hidden>
Date: Mon, 13 Jun 2005 15:16:10 -0400
From: Eric Dorland <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: opensc support

Package: openssh
Followup-For: Bug #231472

Hi,

Now that sarge is released (horray), any thoughts on including this
support in your package. I'm willing to do the heavy lifting, and
probably the best approach would be a seperate package with the opensc
support built in. Let me know what you think.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Any progress on this? Does anybody have feisty package for sc-enabled ssh, or patch or instructions for building it?

Resolving this issue would definitely be helpful...

For some people SSH is useless without smartcard support.
Please resolve.

Still not fixed in gutsy. :-(

*PLEASE* fix this. Some people *will* switch away from Debian and Ubuntu for no other reason than this.

Hello,

You can use my much lighter pkcs11 patch for OpenSSH.
http://alon.barlev.googlepages.com/openssh-pkcs11

It support much more smartcard types, via PKCS#11, and the dependency of pkcs11-helper
is much lighter.
http://www.opensc-project.org/pkcs11-helper/

Best Regards,
Alon Bar-Lev.

BTW: I agree that security without hardware based cryptography worth almost nothing...

The objection Colin has is a valid one. Dependency inflation in the Ubuntu distro is a pernicious and prevalent problem, and he is right to be cautious. Contra to Alon's assertion, most folks in most parts of the world don't need or want hardware cryptography support simply because they don't have the hardware to do the work.

However, it's not all-or-nothing: The package could be compiled with the support for smart card, with the dependency to opensc being "Suggested". The default install would not drag in the extra package, but those who need smart card support could install it.

IMHO

Loye: unfortunately this is not the case. If I build with OpenSC support then the binary will be linked against the OpenSC libraries, and this means that you will have to have those installed otherwise the binary simply won't run at all.

* Colin Watson

| Loye: unfortunately this is not the case. If I build with OpenSC support
| then the binary will be linked against the OpenSC libraries, and this
| means that you will have to have those installed otherwise the binary
| simply won't run at all.

Another option for those wanting to use smart card support is just to
use a different agent than the ssh-agent that comese with ssh.

http://www.fsfe.org/en/fellows/tyrael/fsfe_card_complete_gnupg_ssh_login_how_to
has an explanation on how to get it going (though the udev rules and
such need not be adjusted on newer versions of Ubuntu).

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Why do not handle like situation in exim4: One light flavour w/o Smartcard support and a heavy flavour with all features (and a lot of additional packages) ?

I wish smartcard support too, an heavy floor version of ssh would be great ! Surprisingly it's easier to use smartcards with gentoo than with ubuntu :( ...

smartcard are the state of the art secure technology since 5-10 years please enable it for ssh

I have been using Debian GNU/Linux for 10 years.
I really need smartcard support to secure my SSH and StrongSwan communications.

As written before, smartcard are really secure technologies.
You can buy used smartcard readers on eBay for less than 10 euros.

So please add smartcard support to Openssh.

By the way, most of us only need --with-opensc and opensc libraries so why beg during years for such a common feature.

Can't anyone follow the suggestion of creating an extra openssh-smartcard-opensc and openssh-smartcard-pkcs11 that would use the opensc flag or the pkcs11 patch mentioned in this bug?

If there is no serious reason to avoid it, why is this bug open since 2005??? Come on! An experienced Debian / Ubuntu developer could have done the package in no time at all!

Could you listen to us, please? Or at least provide a satisfactory answer. Mentioning the "dependency hell" surely is not enough (not even by far!!!) when other options such as extra packages exist (and are already in use for other packages).

So, again, PLEASE, do help us and compile it with smartcard support.

Thank you.

invalidated opensc tasks

On Thu, Feb 11, 2010 at 12:42:35AM -0000, J. Javier Maestro wrote:
> Can't anyone follow the suggestion of creating an extra openssh-
> smartcard-opensc and openssh-smartcard-pkcs11 that would use the opensc
> flag or the pkcs11 patch mentioned in this bug?
>
> If there is no serious reason to avoid it, why is this bug open since
> 2005??? Come on! An experienced Debian / Ubuntu developer could have
> done the package in no time at all!

There was a serious reason, even if you don't agree with it -
combinatorial package explosion for each possible option is not a good
thing, and in the long run it creates confusion. "Oh, I just needed to
install openssh-smartcard-opensc-hap-krb5-noavahi and then it all
worked." This is the sort of thing that experienced Debian/Ubuntu
developers learn to think about, because they have the experience of
painting themselves into corners in the past and then having trouble
getting themselves (and their users) out of it.

Fortunately, upstream's smartcard support has been overhauled to use
dynamically loaded PKCS#11 tokens. In the packages of OpenSSH 5.4
(Lucid+1, I'm afraid), we'll be able to have this enabled by default,
which will fix this long-standing bug.

Changes in version 5.4.

[...]

 * Remove the libsectok/OpenSC-based smartcard code and add support for
   PKCS#11 tokens. This support is automatically enabled on all
   platforms that support dlopen(3) and was inspired by patches written
   by Alon Bar-Lev. Details in the ssh(1) and ssh-add(1) manpages.

[...]

http://www.openssh.com/txt/release-5.4

This bug was fixed in the package openssh - 1:5.5p1-3ubuntu1

---------------
openssh (1:5.5p1-3ubuntu1) maverick; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Add support for registering ConsoleKit sessions on login.
    - Drop openssh-blacklist and openssh-blacklist-extra to Suggests; they
      take up a lot of CD space, and I suspect that rolling them out in
      security updates has covered most affected systems now.
    - Convert to Upstart. The init script is still here for the benefit of
      people running sshd in chroots.
    - Install apport hook.
  * Stop setting OOM adjustment in Upstart job; sshd does it itself now.

openssh (1:5.5p1-3) unstable; urgency=low

  * Discard error messages while checking whether rsh, rlogin, and rcp
    alternatives exist (closes: #579285).
  * Drop IDEA key check; I don't think it works properly any more due to
    textual changes in error output, it's only relevant for direct upgrades
    from truly ancient versions, and it breaks upgrades if
    /etc/ssh/ssh_host_key can't be loaded (closes: #579570).

openssh (1:5.5p1-2) unstable; urgency=low

  * Use dh_installinit -n, since our maintainer scripts already handle this
    more carefully (thanks, Julien Cristau).

openssh (1:5.5p1-1) unstable; urgency=low

  * New upstream release:
    - Unbreak sshd_config's AuthorizedKeysFile option for $HOME-relative
      paths.
    - Include a language tag when sending a protocol 2 disconnection
      message.
    - Make logging of certificates used for user authentication more clear
      and consistent between CAs specified using TrustedUserCAKeys and
      authorized_keys.

openssh (1:5.4p1-2) unstable; urgency=low

  * Borrow patch from Fedora to add DNSSEC support: if glibc 2.11 is
    installed, the host key is published in an SSHFP RR secured with DNSSEC,
    and VerifyHostKeyDNS=yes, then ssh will no longer prompt for host key
    verification (closes: #572049).
  * Convert to dh(1), and use dh_installdocs --link-doc.
  * Drop lpia support, since Ubuntu no longer supports this architecture.
  * Use dh_install more effectively.
  * Add a NEWS.Debian entry about changes in smartcard support relative to
    previous unofficial builds (closes: #231472).

openssh (1:5.4p1-1) unstable; urgency=low

  * New upstream release (LP: #535029).
    - After a transition period of about 10 years, this release disables SSH
      protocol 1 by default. Clients and servers that need to use the
      legacy protocol must explicitly enable it in ssh_config / sshd_config
      or on the command-line.
    - Remove the libsectok/OpenSC-based smartcard code and add support for
      PKCS#11 tokens. This support is enabled by default in the Debian
      packaging, since it now doesn't involve additional library
      dependencies (closes: #231472, LP: #16918).
    - Add support for certificate authentication of users and hosts using a
      new, minimal OpenSSH certificate format (closes: #482806).
    - Added a 'netcat mode' to ssh(1): "ssh -W host:port ...".
    - Add the ability to revoke keys in sshd(8) and ssh(1). (For the Debian
      package, this overlaps with the key blacklisting facil...