--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: [openssh] openssh-pki packages creation and state of the art for a more secure OpenSSH
- From: Ludovic Dupont <ludov_dupont@yahoo.fr>
- Date: Sun, 25 May 2008 08:42:43 +0000 (GMT)
- Message-id: <498656.37248.qm@web28601.mail.ukl.yahoo.com>
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?
Aefron.
[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:
openssh-client-udeb_5.4p1-1_i386.udeb
to main/o/openssh/openssh-client-udeb_5.4p1-1_i386.udeb
openssh-client_5.4p1-1_i386.deb
to main/o/openssh/openssh-client_5.4p1-1_i386.deb
openssh-server-udeb_5.4p1-1_i386.udeb
to main/o/openssh/openssh-server-udeb_5.4p1-1_i386.udeb
openssh-server_5.4p1-1_i386.deb
to main/o/openssh/openssh-server_5.4p1-1_i386.deb
openssh_5.4p1-1.debian.tar.gz
to main/o/openssh/openssh_5.4p1-1.debian.tar.gz
openssh_5.4p1-1.dsc
to main/o/openssh/openssh_5.4p1-1.dsc
openssh_5.4p1.orig.tar.gz
to main/o/openssh/openssh_5.4p1.orig.tar.gz
ssh-askpass-gnome_5.4p1-1_i386.deb
to main/o/openssh/ssh-askpass-gnome_5.4p1-1_i386.deb
ssh-krb5_5.4p1-1_all.deb
to main/o/openssh/ssh-krb5_5.4p1-1_all.deb
ssh_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
attached.
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
pp.
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)
-----BEGIN PGP SIGNED MESSAGE-----
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>
Description:
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
Changes:
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.
Checksums-Sha1:
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
Checksums-Sha256:
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
Files:
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer
iD8DBQFLu6sC9t0zAhD6TNERAi7BAJ9CuOPsPweVIdZWYeW46XtLsSEe2wCfSvfN
l+75IGaMwDbORvZOAryllMQ=
=88S0
-----END PGP SIGNATURE-----
--- End Message ---