Re: identity file permissions

From: Derek J. Balling (dredd@megacity.org)
Date: 04/10/03

  • Next message: W Laurentce: "Re: identity file permissions" 
    Date: Wed, 9 Apr 2003 20:35:03 -0400
To: Tim Writer <tim@starnix.com>
From: "Derek J. Balling" <dredd@megacity.org>

    On Wednesday, April 9, 2003, at 08:20 PM, Tim Writer wrote:
    > Instead of creating an identify for the FAX user, why not just add the
    > public
    > keys of all (several hundred) users to the FAX users authorized keys
    > file?
    > Admittedly, this is more work up front (although should be easy to
    > automate)
    > but think about what happens when someone leaves. With your scheme
    > (assuming
    > you can make it work), you would have to issue a new FAX key and
    > inform all
    > (several hundred) FAX users. Some of them won't get the message and
    > some of
    > them will have copied the old FAX key to notebooks or home computers
    > etc. for
    > easy access and you'll be deluged by support calls. With my scheme,
    > you
    > simply remove the user from the FAX users authorized keys file and
    > other
    > users are unaffected.

    Actually, no, the users in question have no actual access to the
    filesystem. Their login shell is our CSR application, so the only
    access they have is what they are explicitly given.

    So yes, generating a key for every user at creation time automatically
    is one solution, but then it requires lots of automation (because our
    users are created via LDAP, so all we do to "create" a user is add them
    to the LDAP server and make their homedir. Now there would be making
    the homedir, creating a key, getting that key over to the fax server,
    etc. etc., and then undo-ing all that when a user is terminated.

    Meanwhile, even if a user COULD get to the private key on the
    application server, when someone is fired, (since the SSH command all
    happens under the hood), we could simply distribute a new private key
    to the application server, a new public key to the fax-server, and
    change it one spot and it's done.

    I certainly recognize the "usual" value that limiting a private key to
    a single user provides, but this (to my thinking anyway) is a pretty
    decent example of where sharing a single private key among the users
    makes a whole lot of sense.

    If I have to do the 'cp' workaround, I will, but I just wish there was
    some way to override the current behavior.

    D

  • Next message: W Laurentce: "Re: identity file permissions"

    Relevant Pages

    • [OT] Re: RSA implementation, please comment.
      ... on a separate server is actually a very good idea, ... This web front uses a well defined and secure ... Don't store the private key on the server. ... Every client gets a smartcard for the decryption (or a HSM, ...
      (comp.lang.perl.misc)
    • now SSL and ids ( was Re: ssh and ids )
      ... > How many simultaneous SSL sessions can be tracked? ... qualifies as a third party having access to the private key. ... communicate with the server in the clear. ... > best protection against covert channels is to stop the attacker before ...
      (Focus-IDS)
    • Re: TIPS FOR THE NEWCOMER
      ... As long as the private key is readable by the ssh client when it comes ... When the ssh client connects to the server, ... private key which matches the public key. ...
      (SSH)
    • Re: Private key generation
      ... As I wrote in my first answer to that thread - there are many situations when key pair is generated on trusted server. ... identity based encryption) simply requires generation of private key on server... ... High assurance keys (especially these that afterward are split in multiple shares using secret sharing schemes) may also require use of specialized equipment and computers that runs in a tempest/EM shielded locations. ... Default scenario supported by Microsoft Certificate Server is the most standard CA mode when CA just signs X509 certificate with emedded public keys. ...
      (microsoft.public.dotnet.security)
    • Re: Location of users private key in PKI solution
      ... If clients and server are Windows platforms, check out CAPICOM as it would ... > It sounds as though I should design the system so that the client ... > application performs the signing operation as that is the most likely ... >> The private key is typically located on the users machine. ...
      (microsoft.public.win2000.security)