[ssh_x509] Allowing all non-revoked keys from a CA

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Fri Sep 13 01:11:50 EEST 2013

Hello Martin,

  I've tried every iteration of subject/DN, etc mangling and I can't
come up with an acceptable (to me) means of managing this scenario.
Ideally I would be able to configure X509 SSH to ignore specific
elements of the presented cert (CN, name, email, etc) and just do CA
and CRL verification.

  I'm willing to sponsor the development of this functionality.  Do
you know who I might be able to contact for that?

Thanks again for all of your help!

On Fri, Sep 6, 2013 at 9:01 AM,  <ssh_x509 at roumenpetrov.info> wrote:
> Hi Kristian,
> do I understand correctly: You are talking about one account to which
> all users should be able to log in? Then, you could issue all
> certificates with the same CN, so they are all allowed to log into that
> account. The CRLs refer to the serial number, not to the CN, so you can
> revoke them separately. Depending on the CA software you could probably
> put the name of the person into a different field which is not included
> in the certificate (just as an information for you, which certificate
> you have issued to whom, in case you want to revoke a specific one). Or,
> if you are running the CA, you can manage a separate list of serial
> numbers and names/email-addresses, just to keep track of the serial
> numbers so that you know which one to revoke.
> If I misunderstood the last paragraph of your previous mail, then there
> is a slight difference between X.509 aware ssh and apache for instance:
> with apache you only check if the client presents a valid certificate,
> but apache normally shows the same content to all users. If there is a
> wiki or cms or something running below, it is up to that software, to
> present different content depending on the context (CN of the client
> cert). Some web applications may be able to create users on-demand in a
> database... there are many different scenarios you could think of. But
> on a linux box or a cluster or where ever the X.509-sshd is running, you
> have pre-existing user accounts, with their entries in the /etc/passwd
> file or LDAP, and their home directories... - well, the latter shouldn't
> be the problem: you can auto-create the homedir with PAM, but somehow at
> least the unix-username should be known on the system, if not in files,
> then at least as an LDAP-entry... but what should be the user-name in
> this case? the same as the CN string? Well, then you could also go the
> other way round (compared to what I proposed in my previous mail): Most
> CA software consist of a collection of scripts (OpenCA for instance uses
> perl scripts), and you could add a section, which sets up the user
> accounts, to the script which is responsible for issuing the
> certificates (provided that your CA machine has root-access to the one
> where the x509sshd is running).
> best regards,
> Martin
> On 05.09.2013 17:24, ssh_x509 at roumenpetrov.info wrote:
>> Hi Martin,
>>   Ideally one could use a mechanism like the one in place for other
>> X.509 aware applications.  Apache httpd, various mail servers, etc all
>> allow the authorization of a client as long as the client presents a
>> cert signed by a configured CA (with an optional CRL for revocations,
>> of course).
>>   I'm not sure how this would be configured with X.509 SSH but
>> providing the CA cert that has signed all other keys as an entry in
>> authorized_keys for the user could be a start.  LDAP could be a nice
>> add-on but should not be necessary.
>>   Essentially I'm looking for a mechanism where a CA and CRL can be
>> defined and login allowed for a given user account for ALL valid
>> cert+key combinations (similar to all other X.509 SSL aware
>> applications).
>> On Thu, Sep 5, 2013 at 3:17 AM,  <ssh_x509 at roumenpetrov.info> wrote:
>>> Hello,
>>> I'm just wondering how you would ensure a correct assignment to the
>>> corresponding accounts. In the authorized_keys file the CN of the
>>> certificate is assigned to the account for which that particular
>>> certificate is valid. Therefore, I believe that you need this
>>> information for the mechanism to work, and you need these files (maybe
>>> I'm wrong and someone else knows a way to work around this problem).
>>> However, assuming you need the authorized_keys files, you could
>>> auto-generate them from the gecos-field of /etc/passwd each time you add
>>> a user (or by a cron job that queries the ldap-server, depending on how
>>> you manage your accounts). If you do so, it is your duty to issue them
>>> with the CN matching that entry when you issue certificates.
>>> Martin
>>> On 05.09.2013 04:06, ssh_x509 at roumenpetrov.info wrote:
>>>> Hello,
>>>>   It's been over a week and I just wanted to check in to see if anyone
>>>> knows how this can be accomplished.
>>>> Thanks!
>>>> On Sat, Aug 24, 2013 at 6:00 PM,  <ssh_x509 at roumenpetrov.info> wrote:
>>>>> Hello,
>>>>>   This has probably been asked before but I can't seem to find any
>>>>> reference of it in my searches.
>>>>>   Is there a way to define an authorized_keys that allows any non-revoked
>>>>> key issued by the CA to authenticate successfully?  In my application I
>>>>> will issue many more keys than I revoke and updating the authorized_keys
>>>>> file for every new cert+key generated somewhat defeats the purpose of the
>>>>> "chain of trust" for me.
>>>>>   I've tried every combination of hacks, docs, etc that I can find or think
>>>>> of to no avail.  Other than that I have everything working perfectly; what
>>>>> a great project!
>>>>> Thanks!
>>>>> --
>>>>> Kristian Kielhofner
>>>>> _______________________________________________
>>>>> ssh_x509 mailing list
>>>>> ssh_x509 at roumenpetrov.info
>>>>> http://roumenpetrov.info/mailman/listinfo/ssh_x509_roumenpetrov.info
>>> _______________________________________________
>>> ssh_x509 mailing list
>>> ssh_x509 at roumenpetrov.info
>>> http://roumenpetrov.info/mailman/listinfo/ssh_x509_roumenpetrov.info
> _______________________________________________
> ssh_x509 mailing list
> ssh_x509 at roumenpetrov.info
> http://roumenpetrov.info/mailman/listinfo/ssh_x509_roumenpetrov.info

Kristian Kielhofner

More information about the ssh_x509 mailing list