smartcard support is not enabled in openssh
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
opensc (Debian) |
Invalid
|
Undecided
|
Unassigned | ||
opensc (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
openssh (Debian) |
Fix Released
|
Unknown
|
|||
openssh (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
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
In Debian Bug tracker #231472, Eric Dorland (eric-debian) wrote : cloning 231472, reassign -1 to ssh-krb5 | #1 |
In Debian Bug tracker #231472, Colin Watson (cjwatson) wrote : Re: Bug#240077: ssh: why not to compile with opensc? | #2 |
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>]
In Debian Bug tracker #231472, Andreas Jellinghaus (tolonuga) wrote : | #3 |
> 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 you
to maintain two openssh versions in parallel.
Thanks for your attention.
Regards, Andreas Jellinghaus
(opensc & openct developer :-)
In Debian Bug tracker #231472, Eric Dorland (eric-debian) wrote : patch to build a ssh-opensc package | #4 |
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.
--
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+
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+
G e h! r- y+
------END GEEK CODE BLOCK------
In Debian Bug tracker #231472, Colin Watson (cjwatson) wrote : Re: Bug#240077: patch to build a ssh-opensc package | #5 |
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>]
In Debian Bug tracker #231472, Eric Dorland (eric-debian) wrote : | #6 |
* 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.
>
> 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.
> 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=2
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...
> 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.
--
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+
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+
G e h! r- y+
------END GEEK CODE BLOCK------
Nicolas Romero (nicolas-romero) wrote : | #7 |
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
Colin Watson (cjwatson) wrote : | #8 |
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.
Nicolas Romero (nicolas-romero) wrote : | #9 |
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...
In Debian Bug tracker #231472, Eric Dorland (eric-debian) wrote : opensc support | #10 |
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=
Debian Bug Importer (debzilla) wrote : | #11 |
Message-Id: <20040206202243
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
Debian Bug Importer (debzilla) wrote : | #12 |
Message-Id: <20040309053510
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
Debian Bug Importer (debzilla) wrote : | #13 |
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>]
Debian Bug Importer (debzilla) wrote : | #14 |
Message-Id: <1080252636.
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...
Debian Bug Importer (debzilla) wrote : | #15 |
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=
Content-
--UlsYxwg8UDQn+EKZ
Content-Type: text/plain; charset=us-ascii
Content-
Content-
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-
Content-
diff -ruN openssh-
--- openssh-
+++ openssh-
@@ -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...
Debian Bug Importer (debzilla) wrote : | #16 |
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>]
Debian Bug Importer (debzilla) wrote : | #17 |
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-
Content-
* 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/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAluo0Yem
OkyoGQfP+
=do8r
-----END PGP SIGNATURE-----
--a8Wt8u1KmwUX3
Debian Bug Importer (debzilla) wrote : | #18 |
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=
In Debian Bug tracker #231472, madduck (madduck) wrote : status? | #19 |
What is the status on this wishlist request?
--
.''`. martin f. krafft <email address hidden>
: :' : proud Debian developer and author: http://
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
always remember you're unique, just like everyone else.
In Debian Bug tracker #231472, David Schmitt (david-schmitt) wrote : | #20 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What is the status on this wishlist request?
Regards, David
PS: Since martin's question is more than a year old, I dare to re-send the
question.
- --
- - hallo... wie gehts heute?
- - *hust* gut *rotz* *keuch*
- - gott sei dank kommunizieren wir über ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFx4i0/
BDBRVS1SgH6K4XU
=5K+f
-----END PGP SIGNATURE-----
In Debian Bug tracker #231472, Colin Watson (cjwatson) wrote : reassign 231472 to openssh, reassign 409844 to openssh, merging 231472 409844 | #21 |
# Automatically generated email from bts, devscripts version 2.8.14
reassign 231472 openssh
reassign 409844 openssh
merge 231472 409844
Changed in openssh: | |
assignee: | kamion → nobody |
status: | Unconfirmed → Confirmed |
Tapani Tarvainen (ubuntu-tapani) wrote : | #22 |
Any progress on this? Does anybody have feisty package for sc-enabled ssh, or patch or instructions for building it?
Guillaume Yziquel (guillaume-yziquel) wrote : | #23 |
Resolving this issue would definitely be helpful...
SunnyBUG (sunnybug) wrote : | #24 |
For some people SSH is useless without smartcard support.
Please resolve.
Tapani Tarvainen (ubuntu-tapani) wrote : | #25 |
Still not fixed in gutsy. :-(
*PLEASE* fix this. Some people *will* switch away from Debian and Ubuntu for no other reason than this.
Alon Bar-Lev (alon-barlev) wrote : | #26 |
Hello,
You can use my much lighter pkcs11 patch for OpenSSH.
http://
It support much more smartcard types, via PKCS#11, and the dependency of pkcs11-helper
is much lighter.
http://
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev (alon-barlev) wrote : | #27 |
BTW: I agree that security without hardware based cryptography worth almost nothing...
Loye Young (loyeyoung) wrote : | #28 |
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
Colin Watson (cjwatson) wrote : | #29 |
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.
Tollef Fog Heen (tfheen) wrote : Re: [Bug 16918] Re: smartcard support is not enabled in openssh | #30 |
* 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://
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
In Debian Bug tracker #231472, Colin Watson (cjwatson) wrote : Re: Bug#481769: add new package with smartcard support: openssh-client-smartcard | #31 |
reassign 355274 openssh
merge 231472 355274 481769
thanks
On Sun, May 18, 2008 at 02:56:30PM +0200, Patrick Winnertz wrote:
> Would it be possible to add a new package: openssh-
> some other name) so that I don't have to recompile my ssh-client every
> time there is a update of openssh? ;)
Merging with other requests. As mentioned in other bugs, my concern is
primarily that of combinatorial explosion with other features. I have
already requested that somebody take on the job of arranging for the
smart card libraries to be opened using dlopen, which would allow this
feature to be shipped by default without imposing extra dependency
requirements. To date, nobody seems to have volunteered.
Cheers,
--
Colin Watson [<email address hidden>]
In Debian Bug tracker #231472, Adam D. Barratt (adam-barratt) wrote : reassign 500445 to openssh, merging 500445 355274 | #32 |
reassign 500445 openssh
merge 500445 355274
Christian Felsing (hostmaster-taunusstein) wrote : | #33 |
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) ?
wizwiz50 (wizwiz50) wrote : | #34 |
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 :( ...
jochen (jbecker) wrote : | #35 |
smartcard are the state of the art secure technology since 5-10 years please enable it for ssh
Kellogs (jm-poure) wrote : | #36 |
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.
Kellogs (jm-poure) wrote : | #37 |
By the way, most of us only need --with-opensc and opensc libraries so why beg during years for such a common feature.
J. Javier Maestro (jjmaestro) wrote : | #38 |
Can't anyone follow the suggestion of creating an extra openssh-
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.
Mitch Towner (kermiac) wrote : | #39 |
invalidated opensc tasks
Changed in opensc (Debian): | |
status: | New → Invalid |
Changed in opensc (Ubuntu): | |
status: | New → Invalid |
Colin Watson (cjwatson) wrote : Re: [Bug 16918] Re: smartcard support is not enabled in openssh | #40 |
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-
> 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-
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.
In Debian Bug tracker #231472, Colin Watson (cjwatson) wrote : merge | #41 |
reassign 493029 openssh 1:5.1p1-1.1
reassign 505277 openssh 1:5.1p1-3
merge 231472 493029 505277
thanks
--
Colin Watson [<email address hidden>]
Changed in openssh (Debian): | |
status: | New → Fix Released |
Changed in openssh (Debian): | |
status: | Fix Released → New |
Changed in openssh (Debian): | |
status: | New → Fix Released |
Pablo Castellano (pablocastellano) wrote : | #42 |
Changes in version 5.4.
[...]
* Remove the libsectok/
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.
[...]
Launchpad Janitor (janitor) wrote : | #43 |
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-
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/
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
authorize
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 VerifyHostKeyDN
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/
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...
Changed in openssh (Ubuntu): | |
status: | Confirmed → Fix Released |
# Automatically generated email from bts, devscripts version 2.7.95.1
clone 231472 -1
reassign -1 ssh-krb5