[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#482806: marked as done ([openssh] openssh-pki packages creation and state of the art for a more secure OpenSSH)

Your message dated Tue, 06 Apr 2010 22:45:13 +0000
with message-id <E1NzHWD-00089n-3t@ries.debian.org>
and subject line Bug#482806: fixed in openssh 1:5.4p1-1
has caused the Debian Bug report #482806,
regarding [openssh] openssh-pki packages creation and state of the art for a more secure OpenSSH
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

482806: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482806
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: openssh
Severity: wishlist

--- Please enter the report below this line. ---
Howdy !

I dare to add a new wish about OpenSSH, though it is not totally unrelated to 
two other recent ones (about smartcards [1] and LDAP [2])... Well, I certainly would not do that without (good, I hope) reasons, which I will try to describe in this (a bit long, I fear - please dont flee!) analysis of the situation I could come up with...

First, there is this quite old official sort-of-support for opensc... but it is not as functionnal as it may seem : it doesn't alter the askpass mechanism, thus fails at loading a private key necessiting a PIN, as it cannot ask for it...

For this to operate smoothly, it takes a patch ; this patch can be found, for instance through apt source, under ./opensc-0.11.1/src/openssh if you get the sources of opensc... and the README mentions clearly that "this patch can add the desired functionality, but [that] it is a crude hack, not meant to be added to openssh releases."

Is this what we really want in a Debian package ?

On the other hand, direct OpenSC support is not what tends to be adopted nowadays... OpenSC implements a whole lot of things, among which PKCS#11 (cryptographic operations requests) and PKCS#15 (data storage), which is great, because maintenance times may force us to directly interact with the datas stored (though not necessarily being able to extract it ; we may simply ask to clear a store, change a pin, extract a public key, etc...); but for authentication, signatures, or ciphering, only PKCS#11 support is needed...

... which is the case for what concerns the smartcard part of my wish... a lot of projects now use or have patches for simple PKCS#11 support, be it through libp11 [3] or pkcs11-helper [4] : OpenSSL, OpenVPN, GnuPG, or... OpenSSH...

One individual is remarkably implied in the quest to bring support for PKCS#11 in free softwares that would benefit from it : Alon Bar-Lev, who has participated in bringing this kind of feature in a lot of softwares [5], maintains a patch that seems to bring a cleaner smartcards support in portable OpenSSH [6].

One advantage of this one towards the dependency hell problematic is that it seems to only, and cool thing - not statically, depend on pkcs11-helper...

The man tries to have his work integrated upstream, but OpenSSH developpement is not so easy to get in, as one may guess ;) . Though he's been in touch with Damien Miller on openssh-unix-dev, this kind of features does not seem to attract that much attention from upstream, who doesn't seem to consider this as a priority of any kind (one must confess they are already busy adding very cool features, such as native chrooting of SSH environment, starting from 4.8p1)...

So instead of having to resort to the "crude hack" from OpenSC sources, if smartcards support should be brought to OpenSSH at the moment, I guess it would have to be through the work of Alon Bar-Lev.

Well... here it is for smartcards... but I guess the problematic is larger... OpenSSH is a very cool and useful piece of software, but maintenability of the keys on a lot of machines is a really heavy task... Alon Bar-Lev pertinently writes on his project page that "People who use PKCS#11 most likely use it in X.509 environment and they wish to use the same identities also with openssh"...

Which leads us to a PKI problematic... if smartcard support (typically RSA 2048 bits keys on Cryptoflex E-Gate 32k, which is all that I found being freely supported with large keys on Linux) could have helped not exposing keys like in the very recent OpenSSL entropy problem, it is of no help in distributing keys accross a lot of machines, which is what this incident has most certainly forced a lot of people to do...

To my knowledge, there are two patch-sets that provide distribution of the public keys that are authorized to be used, and listings of those that are not, both resorting on LDAP.

First one is the LPK patch [7]... sad thing is that it is loosing the support from Inverse Path Ltd, due to the lack of answers from upstream to their merge request, though writer's support will apparently still exist... but above all, I must confess I don't know anything about the compatibility with Alon's patch, so I cannot really advocate in favor of this one or not...

Other one is Roumen Petrov's OpenSSH X.509 patch [8]. Cool thing about this one : Alon Bar-Lev works with him, and patches seem to be made to integrate well together. It adds support for X.509 certificate, which allows to manage the identity inside the key/certificate, and can even get the valid/revoked certificates from an LDAP server (if activated on the ./configure)... though I haven't found a lot of information about the dependency this one may require (a quick look at Gentoo's ebuild, that can activate either LPK's, either Roumen's, patch, but not both at the same time, which is perfectly undestandable, doesn't seem to suggest any kind of mandatory dependency)... and though there are still a few "todo" to achieve (quite minor, IMHO).

To be fair, there also has been a patch from Daniel Hartmeier, together with a validation daemon [9], that has been written, but it did not came into upstream either...

Anyway, I guess the situation could be resumed to this : 

- "opensc" configure option is old and requires a "crude hack", thus should not be considered for integration (as advertised in OpenSC sources README);

- pkcs11 patch seems to be the way, but is not upstream yet;

- people wishing to use PKCS#11 devices are prone to be in a PKI and may want more features;

- there are also two sets of patches that allow LDAP management, and one of them is tailored to work well with PKCS#11's one;

... which in turn, makes me think of what is possible, in order to take the state of the art in consideration :

- invalidate wishes for old and hackish "opensc" flag (reasonable, I guess);

- integrate PKCS#11 patch in OpenSSH, as it doesn't bring static dependencies, though it is not upstream (not very at ease with this one, personnally... OpenSSH is so crucial that it is a risky path, and OpenSSL problem showed how hazardous, though well-intentioned, upstream patching can be dangerous on crucial elements);

- create new additionnal packages (openssh-pki and openssh-server-pki) that would bring PKCS#11, X.509 and OpenLDAP public keys distribution (after having chosen between LPK and Roumen's patch, the latter being notoriously compatible with PKCS#11 support) to those who are willing to accept external patchsets for this kind of functionnalities... 

...I guess feasability about long-term maintenance should at least be discussed with the authors of the patches : but they really seem cooperative, and willing to have their work used, reviewed and told about, so... Alon had proposed Gentoo to maintain the integration of his patch, instead of using the hack from OpenSC sources, and not-upstream patch addition to the standard package has naturally been refused (which doesn't prevent them to propose the hackish opensc way)... but if everyone ignores any initiative of the kind, it will end up with people giving up, like Inverse Path Ltd did...(clearly, I would love to see these two packages created);

- work with upstream patchers, if Debian maintainers feel necessary to modify certain things before begining to package (obvious mitigation faint ;) );

- clearly tell that there won't be any kind of support for this kind of  features until it is integrated upstream, and let users on their own, having to recompile or switch to other distros, may it be at the price of some "crude hack" and chainsawed-homemade-packets&co-crafting (I particularly fear that answer)...

Sorry for this long message (and for its redundancy, well, kind of, as I propose a different path, with two other recent wishes), but as I am thinking of buying some smartcards, just to play with (basically, I intend to take two Cryptoflex E-gate 32k [10], with an Eutronsec SIM+Classic Smart Card+USB flash drive reader, that complies with CCID standard [11]... this reader is sooooo sexy), I am naturally coming across the possibilities... and the lack of it in OpenSSH is a major frustration to me... it is now years since I periodically come across this kind of wishes in bugreports, but it is the first time I really inform myself as much, and think of effectively buying a crypto device...

So I felt I should share the information I gathered about what can be done right now, and the constraints it implies...

... there is a real demand for this (at least 4 years of people dreaming about this kind of thing in this list, though it must be recognized that implementations are still young and not officially supported, which can be mitigated by the facts that some people are working to answer the problematic, and that things now seem better than they may have been, as "serious" patches, ie pretending to be usable, at least do exist) and I wish it could be answered in Debian (or explicitely be told that it definately won't :( ), as this distro has already been able to bring me innovative features that I love (like vserver-enabled-kernel, which is of great use, on machines that do not have enough RAM to have Xen)...

Well... wish is done... any comments?


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481769
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481278
[3] http://www.opensc-project.org/libp11/
[4] http://www.opensc-project.org/pkcs11-helper/
[5] http://alon.barlev.googlepages.com/open-source
[6] http://alon.barlev.googlepages.com/openssh-pkcs11
[7] http://dev.inversepath.com/trac/openssh-lpk
[8] http://www.roumenpetrov.info/openssh/
[9] http://undeadly.org/cgi?action=article&sid=20061204161240&mode=expanded
[10] http://www.cryptoflex.com/Products/cards_egate.html
[11] http://www.eutronsec.it/infosecurity/contents/productline/Details.aspx?IDProd=11&IDFamiglia=3&IDDett1lev=931

--- System information. ---
Architecture: i386
Kernel:       Linux 2.6.24-1-686

Debian Release: lenny/sid
  500 testing         security.debian.org 
  500 testing         ftp.fr.debian.org 

--- Package information. ---
Depends       (Version) | Installed

Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités 
http://mail.yahoo.fr Yahoo! Mail

--- End Message ---
--- Begin Message ---
Source: openssh
Source-Version: 1:5.4p1-1

We believe that the bug you reported is fixed in the latest version of
openssh, which is due to be installed in the Debian FTP archive:

  to main/o/openssh/openssh-client-udeb_5.4p1-1_i386.udeb
  to main/o/openssh/openssh-client_5.4p1-1_i386.deb
  to main/o/openssh/openssh-server-udeb_5.4p1-1_i386.udeb
  to main/o/openssh/openssh-server_5.4p1-1_i386.deb
  to main/o/openssh/openssh_5.4p1-1.debian.tar.gz
  to main/o/openssh/openssh_5.4p1-1.dsc
  to main/o/openssh/openssh_5.4p1.orig.tar.gz
  to main/o/openssh/ssh-askpass-gnome_5.4p1-1_i386.deb
  to main/o/openssh/ssh-krb5_5.4p1-1_all.deb
  to main/o/openssh/ssh_5.4p1-1_all.deb

A summary of the changes between this version and the previous one is

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 482806@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
Colin Watson <cjwatson@debian.org> (supplier of updated openssh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)

Hash: SHA1

Format: 1.8
Date: Tue, 06 Apr 2010 22:38:31 +0100
Source: openssh
Binary: openssh-client openssh-server ssh ssh-krb5 ssh-askpass-gnome openssh-client-udeb openssh-server-udeb
Architecture: source all i386
Version: 1:5.4p1-1
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
 openssh-client - secure shell (SSH) client, for secure access to remote machines
 openssh-client-udeb - secure shell client for the Debian installer (udeb)
 openssh-server - secure shell (SSH) server, for secure access from remote machines
 openssh-server-udeb - secure shell server for the Debian installer (udeb)
 ssh        - secure shell client and server (metapackage)
 ssh-askpass-gnome - interactive X program to prompt users for a passphrase for ssh-ad
 ssh-krb5   - secure shell client and server (transitional package)
Closes: 231472 270399 280609 360151 428082 431538 482806 496843 531561 555625 575725
 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 facility added in
       openssh 1:4.7p1-9, but with different file formats and slightly
       different scopes; for the moment, I've roughly merged the two.)
     - Various multiplexing improvements, including support for requesting
       port-forwardings via the multiplex protocol (closes: #360151).
     - Allow setting an explicit umask on the sftp-server(8) commandline to
       override whatever default the user has (closes: #496843).
     - Many sftp client improvements, including tab-completion, more options,
       and recursive transfer support for get/put (LP: #33378).  The old
       mget/mput commands never worked properly and have been removed
       (closes: #270399, #428082).
     - Do not prompt for a passphrase if we fail to open a keyfile, and log
       the reason why the open failed to debug (closes: #431538).
     - Prevent sftp from crashing when given a "-" without a command.  Also,
       allow whitespace to follow a "-" (closes: #531561).
   * Fix 'debian/rules quilt-setup' to avoid writing .orig files if some
     patches apply with offsets.
   * Include debian/ssh-askpass-gnome.png in the Debian tarball now that
     we're using a source format that permits this, rather than messing
     around with uudecode.
   * Drop compatibility with the old gssapi mechanism used in ssh-krb5 <<
     3.8.1p1-1.  Simon Wilkinson refused this patch since the old gssapi
     mechanism was removed due to a serious security hole, and since these
     versions of ssh-krb5 are no longer security-supported by Debian I don't
     think there's any point keeping client compatibility for them.
   * Fix substitution of ETC_PAM_D_SSH, following the rename in 1:4.7p1-4.
   * Hardcode the location of xauth to /usr/bin/xauth rather than
     /usr/bin/X11/xauth (thanks, Aron Griffis; closes: #575725, LP: #8440).
     xauth no longer depends on x11-common, so we're no longer guaranteed to
     have the /usr/bin/X11 symlink available.  I was taking advantage of the
     /usr/bin/X11 symlink to smooth X's move to /usr/bin, but this is far
     enough in the past now that it's probably safe to just use /usr/bin.
   * Remove SSHD_OOM_ADJUST configuration.  sshd now unconditionally makes
     itself non-OOM-killable, and doesn't require configuration to avoid log
     spam in virtualisation containers (closes: #555625).
   * Drop Debian-specific removal of OpenSSL version check.  Upstream ignores
     the two patchlevel nybbles now, which is sufficient to address the
     original reason this change was introduced, and it appears that any
     change in the major/minor/fix nybbles would involve a new libssl package
     name.  (We'd still lose if the status nybble were ever changed, but that
     would mean somebody had packaged a development/beta version rather than
     a proper release, which doesn't appear to be normal practice.)
   * Drop most of our "LogLevel SILENT" (-qq) patch.  This was originally
     introduced to match the behaviour of non-free SSH, in which -q does not
     suppress fatal errors, but matching the behaviour of OpenSSH upstream is
     much more important nowadays.  We no longer document that -q does not
     suppress fatal errors (closes: #280609).  Migrate "LogLevel SILENT" to
     "LogLevel QUIET" in sshd_config on upgrade.
   * Policy version 3.8.4:
     - Add a Homepage field.
 6ee9e148ad9cf2a41c9739e7965d4c0a718668ae 1694 openssh_5.4p1-1.dsc
 2a3042372f08afb1415ceaec8178213276a36302 1094604 openssh_5.4p1.orig.tar.gz
 7379e94c120ed0d3f17eac6aabe32f840a487b8f 233154 openssh_5.4p1-1.debian.tar.gz
 43273fef00b41b1922fcf16f1a923a2d9c0bd56c 1240 ssh_5.4p1-1_all.deb
 864e5c7c5efd1dc734d8759e68c8ad0b4ed93fed 93012 ssh-krb5_5.4p1-1_all.deb
 ad9b4a4f0bd27e04a43e9ff82750572457613950 875794 openssh-client_5.4p1-1_i386.deb
 a8969c78a0095b2640d6357340ee1b4e9b3621d2 297168 openssh-server_5.4p1-1_i386.deb
 df0666a31c0ea53070eee66ed16b8fef666b0564 100386 ssh-askpass-gnome_5.4p1-1_i386.deb
 801090e864540ee1342f7016ab9b643b43338075 193232 openssh-client-udeb_5.4p1-1_i386.udeb
 1f4c2cf71da9c384b6e48c01d0c72d8e5a6349d6 218024 openssh-server-udeb_5.4p1-1_i386.udeb
 b58014a46751c6876cf2abac8c1b4ff7691fe0787ffe3a2fdb094990c3741b77 1694 openssh_5.4p1-1.dsc
 ae96e70d04104824ab10f0d7aaef4584ac96b2a870adfcd8b457d836c8c5404e 1094604 openssh_5.4p1.orig.tar.gz
 6971cbdcb59cea5dda29fe5c31939c3415f50635897d74a82dd8a47954398064 233154 openssh_5.4p1-1.debian.tar.gz
 705fca4ded8f01f979f5d2d67307f77fa9249378cc648b1b1e9f5de3bd5d4ac8 1240 ssh_5.4p1-1_all.deb
 4ad7484b82c45881c756a5f526660942cd48fc0ee945448980c4aa836ec6e562 93012 ssh-krb5_5.4p1-1_all.deb
 94b0cfcb92f58d30147022d86a277200bd700a80877c917fae67d4c33ebf5051 875794 openssh-client_5.4p1-1_i386.deb
 8108aecb229def39e38ccdcd68940ca7511177d7c04513bcd152755aa493c9bb 297168 openssh-server_5.4p1-1_i386.deb
 926472da43dee63355e2478a04c426b5a6af4a0f1d300f13c6825a9105c0f703 100386 ssh-askpass-gnome_5.4p1-1_i386.deb
 5f3d90b896c39976432e4a1a003578945f044faa786dff13eb6f6769552e829b 193232 openssh-client-udeb_5.4p1-1_i386.udeb
 e85187674d0b3b7e42780d10b9f163d297e372269cac1d7ab9f593dc4d38ef2f 218024 openssh-server-udeb_5.4p1-1_i386.udeb
 632afff272e44d3ed316e78566dfc746 1694 net standard openssh_5.4p1-1.dsc
 da10af8a789fa2e83e3635f3a1b76f5e 1094604 net standard openssh_5.4p1.orig.tar.gz
 b7f81be1721ff7a9701069198b02dba5 233154 net standard openssh_5.4p1-1.debian.tar.gz
 3b7776f10b9fd2ef5911db5ebd48ae5a 1240 net extra ssh_5.4p1-1_all.deb
 2f9e0b2b11912749e1dde01f38d1a1f1 93012 net extra ssh-krb5_5.4p1-1_all.deb
 984ad564b3c6fa2d73036ab50b68353f 875794 net standard openssh-client_5.4p1-1_i386.deb
 9394971388afc25b31500d435ae8af65 297168 net optional openssh-server_5.4p1-1_i386.deb
 e5abea75351c1737d6f4f61bd23983b8 100386 gnome optional ssh-askpass-gnome_5.4p1-1_i386.deb
 04e5101bcc8b4d02904efb8bbc169b9c 193232 debian-installer optional openssh-client-udeb_5.4p1-1_i386.udeb
 2debab4885b293f2777b2ee36cbcbeaa 218024 debian-installer optional openssh-server-udeb_5.4p1-1_i386.udeb
Package-Type: udeb

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer


--- End Message ---

Reply to: