Hello All, As I promised, I've completed and initial patch for openssh PKCS#11 support. The same framework is used also by openvpn. I want to help everyone who assisted during development. This patch is based on the X.509 patch from http://roumenpetrov.info/openssh/ written by Rumen Petrov, supporting PKCS#11 without X.509 looks like a bad idea. *So the first question is: What is the merge status of Ruman's patch?* The PKCS#11 patch modify ssh-add and ssh-agent to support PKCS#11 private keys and certificates. It allows using multiple PKCS#11 providers at the same time, selecting keys by id, label or certificate subject, handling card removal and card insert events, supports card insert to a different slot, handling session expiration. One significant change is that the ssh-agent prompts for passwords now... So you need to configure it with a program that asks for PIN, a program such as x11-ssh-askpass. Current implementation (ssh-add asks for passwords) is not valid for dynamic smartcard environment. *So the second question is whether this approach of handling passwords is valid for merge?* Current implementation uses the askpin program also for promoting card insert... Don't be confused, it only expects ok or cancel. If we continue in merge I will also allow select a different program for card prompt. A common scenario is the following: $ ssh-agent xterm -> $ ssh-add --pkcs11-ask-pin `which x11-ssh-askpass` $ ssh-add --pkcs11-add-provider --pkcs11-provider /usr/lib/pkcs11/MyProvider.so $ ssh-add --pkcs11-add-id --pkcs11-slot-type label --pkcs11-slot "MyToken" --pkcs11-id-type subject --pkcs11-id "/C=XX/CN=YY" $ ssh myhost In order to see available object, you can use: $ ssh-add --pkcs11-show-slots --pkcs11-provider /usr/lib/pkcs11/MyProvider.so Opensc users should add: --pkcs11-sign-mode sign $ ssh-add --pkcs11-show-objects --pkcs11-provider /usr/lib/pkcs11/MyProvider.so --pkcs11-slot 0 Look at ssh-add for more options. If this patch is finally accepted, I believe that all opensc code can be removed from all components of openssh, and simply use the opensc PKCS#11 provider. Some general comments 1. I think that ssh-add should be cleaned up, and support arguments properly, the openbsd-compact does not getopt_long. 2, I think that it is best that ssh-agent have a configuration file, so that static configurations may be provided, also ssh-agent lacks logging in none debugging mode, this should also be corrected. 3. I don't support reader plug&play for now... Since PKCS#11 does not support it. It can be supported on the price of invalidating all open sessions. Looking forward to receive any comments, Best Regards, Alon Bar-Lev.
Hello Andreas, Thank you for your quick feed-back! Andreas Jellinghaus wrote:> compile error :) > > gcc 4.0.* (current kubunto 5.10). > > compiles fine with gcc 3.4.Sorry... I'd put prototype in-side function... Strange that gcc 4 does not accept it... Please tell me if moving "static void usage (void);" to global scope helps.> Some other notes from my side: > - a version without x.509 would be great. from my point of view x.509 is > something most people don't need and a huge source of complexity > with very little benefit. most people work much better with rsa keys only, > not with (ca signed) certificates, cert chains, lists of trusted cas, crls, > and all the other stuff. for the small scale it is a HUGE overhead with > much more cost than pay off.I don't agree... You can use self-signed certificates for small scale... You get the same complexity of RSA keys. Then the implementation handles only one format of authentication method... The usage of self-signed certificates should be integrated into the ssh-keygen and then it will be as simple as using rsa keys. I hope I won't regret this... But... I think that ssh should use X.509 (self-signed and not) or kerberos identities, TLS as protocol, and PKCS#11 as cryptographic interface... If you drop all proprietary implementations, I think you find a much simpler code and simpler user experience. Anyway... if X.509 patch will not be merged, I will implement RSA only implementation... Although I think it is a mistake.> ironically now that people use x.509 large scale we see it doesn't work > for them either. like the us dod with a CRL > 50 mb or belgium with a > similar big CRL.This issue can be easily resolved using a proper algorithm... If this is the last issue that blocks X.509 merging, I can work with Rumen in order to hash CRL in order to handle large CRLs. Another approach may be to trust each authorized end certificate, and leave out the X.509 hierarchy... You get the same management difficulties of RSA keys... But without the overhead of X.509. For a conclusion, if you are open for it... I think we should discuses the X.509 issue more deeply...> - how can I use the ssh command with my pkcs#11 module? > the binary tells me: no support for smart cards. I think it is very > important to have direct ssh support, too.You run ssh-agent xterm, then in the opened xterm you simply ssh... Oh... You want to run ssh without ssh-agent...?!?! I think you can write a simple script and then use: $ ssh-agent script Again... If it is required, I will add this... But maybe a better design is to remove all private key code from ssh and make ssh fork ssh-agent as a child... Or making ssh-agent a library... Some help regarding X.509... If that what you meant... You should add the CA into /etc/ssh/ca/ca-bundle.crt (PEM). You should add the following to ~/.ssh/authorized_keys x509v3-sign-rsa subject=/C=XX/CN=YY Also try MandatoryCRL no in /etc/sshd_config> > - ssh-add: why new --options? openssh has lots of options that > can be placed in the config file or given via -o Option=Value. > I think it would be very user friendly to be able to put the options > in the config file, and then also pass them as usual with -o.1. ssh-add does not read config file... 2. I think that ssh-add should be called in script... 3. Most of static options (provider, askpin) should be of ssh-agent... This is part of my note for maintainers... I will read all static options from config file.> - I'm not sure why the agent needs the ask pin program. can you > explain? (I thought you give the pin when you add a key, and if > the card is removed or something like that, the agent simply > drops it, so you have to add it again).I don't think it is comfortable for the user to execute commands if he remove/insert his card, and after expiration... Current implementation prompt for PIN (if needed) when you ssh... I think it is the best. If most user think that ssh-agent should forget keys I will alter current behavior. I think a better implementation would be to allow the ssh-agent notify ssh that a password is required along with a prompt, than ssh will get this password and forward it to the agent...> - the --pkcs11-add-id option: why not use the "normal" > "-s 0" instead of --pkcs11-add-id --pkcs11-slot 0I wanted to make the interface as generic as I could... Most user will NOT use the slot id... Most (I hope) will prefer to use the --pkcs11-slot-type label --pkcs11-slot "token label" since it will find the right slot based on their token label, so they can insert their token to any slot. In opensc implementation you must specify slot id... So I can make an alias and accept -s argument...> > - are --pkcs11-id-type and --pkcs11-id required? what is the > default? could be wrapped into a complex string like > "-s 0:id:0" or "-s 0:label:Andreas Jellinghaus" or similar. > that would be at least a lot less to type :)I prefer options to be clear... Even if I need to type some more... I will be happy to receive more comments on this...> - what exactly does --pkcs11-protected-authentication ?If you have external key-pad or biometric support, you need to pass NULL to C_Login...> > Sorry, need to go now, will test later.Looking forward!> > Thanks for your patch, great work!Thanks!> > Regards, Andreas >Best Regards, Alon Bar-Lev.
Andreas Jellinghaus wrote:> Hi Alon, > >>I don't agree... >>You can use self-signed certificates for small scale... You >>get the same complexity of RSA keys. > > > no, for example x.509 patch will still check validity times and > refuse expired certificates. that is additional complexity. > > think of the horror if your only way to login as root on some > machine is certificate based, it expires, and now you are no > longer allowed to login. sorry, but that is not a scenario I want. >Again... I don't agree... You can set the default validFrom, validTo of self-signed certificates to be from beginning of time to the end of time. So it will behave exactly the same as RSA keys.>>I think that ssh should use X.509 (self-signed and not) or >>kerberos identities, TLS as protocol, and PKCS#11 as >>cryptographic interface... If you drop all proprietary >>implementations, I think you find a much simpler code and >>simpler user experience. > > > please address only one issue at a time. if the issue is pkcs#11, > then it should be addressed on base of the current openssh > code (without x.509) I think. if you bundle several issues you risk > getting all rejected because of one part.I don't agree... If I implement PKCS#11, I should consider how people mostly use PKCS#11... As generic as PKCS#11 is, it is used in X.509 environment where it hold a private key and a certificate. In the none-standard environments (ssh, gpg) people tend to use only raw keys. Part of my mission of adding support for PKCS#11 interface to open source applications is to make them more standard, so that they can be used in environments where it was difficult to be used so far.>>Anyway... if X.509 patch will not be merged, I will >>implement RSA only implementation... > > > from my point of view it would be great to have both. > if pkcs#11 is accepted into openssh, then roumen > will most likely accept patches to improve x.509 patch > to play well with pkcs#11, too.These are not two separate issues. If openssh will not support X.509, I will still require X.509 certificate on the PKCS#11 token. I will not support a tokens that are outside of X.509 world.> >>You run ssh-agent xterm, > doesn't help me on a console.You can use ssh-agent ssh.... :)>>You want to run ssh without ssh-agent...?!?! I > > yes. for example If I'm working at the console of > one server (plain virtual console, no agent, no X) > and then need to log in on other machines to get updates > pulled. I would want to plugin/out my token all the > time, but rather > ssh -I 0 otherserver > to login remote. > > that currently works. if you want to replace opensc support, > the feature set should not shrink. > > true, you can hack work arounds, but that would be still unfriendly > to the users, when right now they can use "ssh -I 0 ...".OK... If all be accepted with the agent, I will patch ssh also. Although I think current design can be improved if ssh-agent will be implemented as a library and be used by ssh if it cannot find running ssh-agent. There is no point in duplicating code...>>Some help regarding X.509... If that what you meant... >>You should add the CA into /etc/ssh/ca/ca-bundle.crt (PEM). >>You should add the following to ~/.ssh/authorized_keys >>x509v3-sign-rsa subject=/C=XX/CN=YY > > > well, that exactly demonstrates that a CA can create man in the > middle attacks by issuing key/certs to several people with the same > subject. nobody will notice. > > I like ssh because it is plain, simple, secure.You can still use public key hash... I simply don't like it... So it only demonstrate that ssh can be plain, simple, secure... :)> but back to the issue: please take a look at pam_pkcs11. > sure, it is for login, but they have lots of mappers to implement > such shemas or other ideas. maybe it would be helpful to > implement the same concepts and make the config look the > same? would be a nice service for users.True... pam_pkcs11 did a wonderful work on parsing extensions... You can provide it as a library then it can be used by many applications.>>1. ssh-add does not read config file... > > ouch. but does it have to, if it communicates with ssh-agent? > (or does the agent neither read the config file?)ssh, ssh-add find their agent by looking on environment variables.>>2. I think that ssh-add should be called in script... > > no issue here. -o SomeOption=somevalue > should work, I guess?Not on current up-stream implementation.>>I don't think it is comfortable for the user to execute >>commands if he remove/insert his card, and after expiration... >>Current implementation prompt for PIN (if needed) when you >>ssh... I think it is the best. > > > sorry, I disagree. the point of the ssh agent if for many people > so they can create scripts and have non interactive tasks. > if you suddenly halt somewhere in the middle and prompt > for pins, you might confuse users and break those scripts. > people expect it to work. or to fail. but if something hangs > because input is asked somewhere, that is very, very confusing > and hard to debug.1. If you don't askpin program, ssh-agent will fail and won't prompt anything. 2. You can config your own askpass program that takes the PIN from other place (Like environment or file)>>If most user think that ssh-agent should forget keys I will >>alter current behavior. > > if cards are removed? I think so. the current does not, > which is also ok, because (at least with usb crypto tokens) > you can hook to the hotplug event and run ssh-add -D > and xlock.Well... I will be glad to receive other comments regarding this... I really don't think so...> btw: I wonder what everyone thinks about this: > do you think it would be ok security wise, to have a screen > lock that not only requires card and pin to unlock, but > also adds the pin to agents like the ssh agent?I think that unlock should be enough...>>I prefer options to be clear... Even if I need to type some >>more... I will be happy to receive more comments on this... > > > you could have long+short options like most apps? > or - my preference - config file options.All can be provided... But first major issues should be agreed upon... (PIN handling, X.509) Best Regards, Alon Bar-Lev.
Apparently Analagous Threads
- [ANNOUNCE] PKCS#11 support in OpenSSH 4.3p2 (version 0.11)
- Re-adding PKCS#11 key in ssh-agent produces "agent refused operation" error.
- [ANNOUNCE] PKCS#11 support in OpenSSH 4.3p2 (version 0.07)
- Re-adding PKCS#11 key in ssh-agent produces "agent refused operation" error.
- [Bug 1371] New: Add PKCS#11 (Smartcards) support into OpenSSH