This is a discussion on Re: openssh PKCS#11 support - openssh ; 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 ...
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
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
>>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
> 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,
> 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
>>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)
openssh-unix-dev mailing list