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

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Fri Sep 13 11:04:37 EEST 2013


Hi Kristian,

Roumen Petrov is the maintainer of the code. He announces new releases 
on this list. We are just using X.509 ssh in our environment and therefore
I have some experience. But usually Roumen also replies to questions here.
He might be on vacation or conferences. 

On 13.09.2013 00:11, ssh_x509 at roumenpetrov.info wrote:
> 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
>
>


-- 
Dr. Martin Hecht
High Performance Computing Center Stuttgart (HLRS)
HPC Production, Office 0.051
University of Stuttgart
Nobelstraße 19, 70569 Stuttgart, Germany
Tel: +49(0)711/685-65799  Fax: -55799
Mail: hecht at hlrs.de





More information about the ssh_x509 mailing list