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 0


I 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.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev