Force non-empty pass-phrase? - SSH

This is a discussion on Force non-empty pass-phrase? - SSH ; Does anybody know of a way to enforce a policy where ssh key pass-phrases should not be empty? It is one of the "weaknesses" of ssh as I see it that an administrator can't actually impose this constraint on access ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: Force non-empty pass-phrase?

  1. Force non-empty pass-phrase?

    Does anybody know of a way to enforce a policy where ssh key pass-phrases
    should not be empty? It is one of the "weaknesses" of ssh as I see it that
    an administrator can't actually impose this constraint on access to his
    own server.

    I realise that the next argument may be that "users can always use a weak
    pass-phrase" but I see a big difference between a pass-phrase or none at
    all. And I think many/most users would probably bother to setup
    keychain/ssh-agent once they were forced to use a pass-phrase.

  2. Re: Force non-empty pass-phrase?

    >>>>> "mark" == mark writes:

    mark> Does anybody know of a way to enforce a policy where ssh key
    mark> pass-phrases should not be empty? It is one of the "weaknesses"
    mark> of ssh as I see it that an administrator can't actually impose
    mark> this constraint on access to his own server.

    He can't, because it makes no sense. The server never sees the user's
    private key. It has no control over where or how the key is stored. It's
    like suggesting there's a lock out there that can "require" that you not
    keep the key in your pocket.

    --
    Richard Silverman
    res@qoxp.net


  3. Re: Force non-empty pass-phrase?

    Richard E. Silverman wrote:
    >>>>>> "mark" == mark writes:

    >
    > mark> Does anybody know of a way to enforce a policy where ssh key
    > mark> pass-phrases should not be empty? It is one of the
    > "weaknesses" mark> of ssh as I see it that an administrator can't
    > actually impose mark> this constraint on access to his own server.
    >
    > He can't, because it makes no sense. The server never sees the user's
    > private key. It has no control over where or how the key is stored.
    > It's like suggesting there's a lock out there that can "require" that
    > you not keep the key in your pocket.


    Richard? You could make the lock *REALLY, REALLY, REALLY* big so that the
    key has to be at least as big. But that doesn't sound like a good idea,
    either.



  4. Re: Force non-empty pass-phrase?

    On Thu, 27 Apr 2006 00:52:27 -0400, Richard E. Silverman wrote:
    >>>>>> "mark" == mark writes:

    > mark> Does anybody know of a way to enforce a policy where ssh key
    > mark> pass-phrases should not be empty? It is one of the "weaknesses"
    > mark> of ssh as I see it that an administrator can't actually impose
    > mark> this constraint on access to his own server.
    >
    > He can't, because it makes no sense. The server never sees the user's
    > private key. It has no control over where or how the key is stored. It's
    > like suggesting there's a lock out there that can "require" that you not
    > keep the key in your pocket.


    Richard, of course I realise that it doesn't "make sense" wrt to the
    fundamental design of ssh. The pass-phrase is only pertinent to
    unlocking the user's private key and that is that. But surely it does
    make "make sense" that an administrator may have a personal opinion that
    users should not be allowed to use empty pass-phrases on their keys?
    What I am saying is that it has always seemed to me a bit of a
    deficiency of ssh that an administrator can not actually enforce this
    policy on users to whom he is granting access to his server?

    I guess it would be possible to write a script for root to traverse over
    unix users client side home areas attempting to do some kind of
    ssh-keygen operation on their keys and confirming that a pass-phrase is
    prompted for? This doesn't address remote putty users etc, though.


  5. Re: Force non-empty pass-phrase?

    >>>>> "NKG" == Nico Kadel-Garcia writes:

    NKG> Richard E. Silverman wrote:
    >>>>>>> "mark" == mark writes:

    >>

    mark> Does anybody know of a way to enforce a policy where ssh key
    mark> pass-phrases should not be empty? It is one of the
    >> "weaknesses" mark> of ssh as I see it that an administrator can't
    >> actually impose mark> this constraint on access to his own server.
    >>
    >> He can't, because it makes no sense. The server never sees the
    >> user's private key. It has no control over where or how the key is
    >> stored. It's like suggesting there's a lock out there that can
    >> "require" that you not keep the key in your pocket.


    NKG> Richard? You could make the lock *REALLY, REALLY, REALLY* big so
    NKG> that the key has to be at least as big. But that doesn't sound
    NKG> like a good idea, either.

    But this assumes the key size scales at least linearly with the size of
    the lock...

    --
    Richard Silverman
    res@qoxp.net


  6. Re: Force non-empty pass-phrase?

    >>>>> "mark" == mark writes:

    mark> On Thu, 27 Apr 2006 00:52:27 -0400, Richard E. Silverman wrote:
    >>>>>>> "mark" == mark writes:

    mark> Does anybody know of a way to enforce a policy where ssh key
    mark> pass-phrases should not be empty? It is one of the "weaknesses"
    mark> of ssh as I see it that an administrator can't actually impose
    mark> this constraint on access to his own server.
    >> He can't, because it makes no sense. The server never sees the
    >> user's private key. It has no control over where or how the key is
    >> stored. It's like suggesting there's a lock out there that can
    >> "require" that you not keep the key in your pocket.


    mark> Richard, of course I realise that it doesn't "make sense" wrt to
    mark> the fundamental design of ssh. The pass-phrase is only pertinent
    mark> to unlocking the user's private key and that is that. But surely
    mark> it does make "make sense" that an administrator may have a
    mark> personal opinion that users should not be allowed to use empty
    mark> pass-phrases on their keys? What I am saying is that it has
    mark> always seemed to me a bit of a deficiency of ssh that an
    mark> administrator can not actually enforce this policy on users to
    mark> whom he is granting access to his server?

    Of course he should have an opinion, and communicate that to his users --
    but that's a matter of policy. Calling it a deficiency of SSH implies (at
    least to me) that there's some technical means by which an SSH server
    *could* enforce this policy, and the protocol or its implementations
    simply aren't using it. I know of no such means, and would be interested
    to hear if you have an idea.

    --
    Richard Silverman
    res@qoxp.net


  7. Re: Force non-empty pass-phrase?

    mark wrote:

    > I guess it would be possible to write a script for root to traverse
    > over unix users client side home areas attempting to do some kind of
    > ssh-keygen operation on their keys and confirming that a pass-phrase
    > is prompted for?


    I would not allow any SSH server to execute arbitrary code with the
    permissions of my client side user account. (And this could not prevent
    "malicious" users from deliberately using a key with a blank passphrase
    either. The client could always manipulate the server's control process
    and its environment.)

    Paul

  8. Re: Force non-empty pass-phrase?

    Paul Hink wrote:
    > mark wrote:
    >
    >> I guess it would be possible to write a script for root to traverse
    >> over unix users client side home areas attempting to do some kind of
    >> ssh-keygen operation on their keys and confirming that a pass-phrase
    >> is prompted for?

    >
    > I would not allow any SSH server to execute arbitrary code with the
    > permissions of my client side user account. (And this could not
    > prevent "malicious" users from deliberately using a key with a blank
    > passphrase either. The client could always manipulate the server's
    > control process and its environment.)


    I've done that as an administrator in NFS based environments, and given
    users gentle warnings about NFS published home directories with no password
    SSH keys in them. It's a serious no-no in such an environment, since anyone
    can pretend to be the user with a simple NFS client and access all their
    files.



  9. Re: Force non-empty pass-phrase?

    Richard E. Silverman wrote:

    >> Richard? You could make the lock *REALLY, REALLY, REALLY* big so
    >> that the key has to be at least as big. But that doesn't sound
    >> like a good idea, either.

    >
    > But this assumes the key size scales at least linearly with the size
    > of the lock...


    Well, yeah. SSH servers could force a minimum key-length, making them 2 Gig
    or so minimum. Of course, this becomes completely workable really, really
    fast....



  10. Re: Force non-empty pass-phrase?

    Nico Kadel-Garcia wrote:

    > I've done that as an administrator in NFS based environments, and
    > given users gentle warnings about NFS published home directories with
    > no password SSH keys in them. It's a serious no-no in such an
    > environment, since anyone can pretend to be the user with a simple
    > NFS client and access all their files.


    If "anyone can pretend to be the user with a simple NFS client and
    access all their files" there are different and more serious problems
    than SSH keys with blank passwords.

    Paul

  11. Re: Force non-empty pass-phrase?

    Paul Hink wrote:
    > Nico Kadel-Garcia wrote:
    >
    >> I've done that as an administrator in NFS based environments, and
    >> given users gentle warnings about NFS published home directories with
    >> no password SSH keys in them. It's a serious no-no in such an
    >> environment, since anyone can pretend to be the user with a simple
    >> NFS client and access all their files.

    >
    > If "anyone can pretend to be the user with a simple NFS client and
    > access all their files" there are different and more serious problems
    > than SSH keys with blank passwords.


    Welcome to NFS, brother. There's a compelling reason it's called "No
    Freaking Security".



  12. Re: Force non-empty pass-phrase?

    >>>>> "NKG" == Nico Kadel-Garcia writes:

    NKG> Paul Hink wrote:
    >> Nico Kadel-Garcia wrote:
    >>> I've done that as an administrator in NFS based environments, and
    >>> given users gentle warnings about NFS published home directories
    >>> with no password SSH keys in them. It's a serious no-no in such an
    >>> environment, since anyone can pretend to be the user with a simple
    >>> NFS client and access all their files.

    >> If "anyone can pretend to be the user with a simple NFS client and
    >> access all their files" there are different and more serious
    >> problems than SSH keys with blank passwords.


    NKG> Welcome to NFS, brother. There's a compelling reason it's called
    NKG> "No Freaking Security".

    It's worth noting that this is not necessarily so. Where I work, we are
    right now in the process of kerberizing all our NFS shares, which provides
    real authentication, integrity, and encryption. Actually, it's true that
    NFS proper has no security features per se; that's left to its transport.
    All you need do is use a secure RPC underneath it.

    --
    Richard Silverman
    res@qoxp.net


  13. Re: Force non-empty pass-phrase?

    Nico Kadel-Garcia wrote:
    > Paul Hink wrote:
    >> Nico Kadel-Garcia wrote:
    >>
    >>> I've done that as an administrator in NFS based environments, and
    >>> given users gentle warnings about NFS published home directories
    >>> with no password SSH keys in them. It's a serious no-no in such an
    >>> environment, since anyone can pretend to be the user with a simple
    >>> NFS client and access all their files.

    >>
    >> If "anyone can pretend to be the user with a simple NFS client and
    >> access all their files" there are different and more serious
    >> problems than SSH keys with blank passwords.

    >
    > Welcome to NFS, brother. There's a compelling reason it's called "No
    > Freaking Security".


    Then why bother about blank SSH key passphrases at all? These keys have
    to be regarded as compromised anyway.

    Paul

  14. Re: Force non-empty pass-phrase?

    On 2006-04-28, Richard E. Silverman wrote:
    >>>>>> "mark" == mark writes:


    > mark> always seemed to me a bit of a deficiency of ssh that an
    > mark> administrator can not actually enforce this policy on users to
    > mark> whom he is granting access to his server?
    >
    > Of course he should have an opinion, and communicate that to his users --
    > but that's a matter of policy. Calling it a deficiency of SSH implies (at
    > least to me) that there's some technical means by which an SSH server
    > *could* enforce this policy, and the protocol or its implementations
    > simply aren't using it. I know of no such means, and would be interested
    > to hear if you have an idea.


    Sounds like using keys alone is not what Mark wants. Hardware tokens then?

    --
    Elvis Notargiacomo master AT barefaced DOT cheek
    http://www.notatla.org.uk/goen/
    Powergen write "Why not stay with us" - let me count the ways!

  15. Re: Force non-empty pass-phrase?

    >>>>> "all" == all mail refused writes:

    all> On 2006-04-28, Richard E. Silverman wrote:
    >>>>>>> "mark" == mark writes:


    mark> always seemed to me a bit of a deficiency of ssh that an
    mark> administrator can not actually enforce this policy on users to
    mark> whom he is granting access to his server?
    >> Of course he should have an opinion, and communicate that to his
    >> users -- but that's a matter of policy. Calling it a deficiency of
    >> SSH implies (at least to me) that there's some technical means by
    >> which an SSH server *could* enforce this policy, and the protocol
    >> or its implementations simply aren't using it. I know of no such
    >> means, and would be interested to hear if you have an idea.


    all> Sounds like using keys alone is not what Mark wants. Hardware
    all> tokens then?

    This could work, as long as he locks down the server so that only the
    sysadmin can authorize keys for login.

    --
    Richard Silverman
    res@qoxp.net


  16. Re: Force non-empty pass-phrase?

    >>>>> "PH" == Paul Hink writes:

    PH> Nico Kadel-Garcia wrote:
    >> Paul Hink wrote:
    >>> Nico Kadel-Garcia wrote:
    >>>> I've done that as an administrator in NFS based environments, and
    >>>> given users gentle warnings about NFS published home directories
    >>>> with no password SSH keys in them. It's a serious no-no in such
    >>>> an environment, since anyone can pretend to be the user with a
    >>>> simple NFS client and access all their files.
    >>> If "anyone can pretend to be the user with a simple NFS client
    >>> and access all their files" there are different and more serious
    >>> problems than SSH keys with blank passwords.

    >> Welcome to NFS, brother. There's a compelling reason it's called
    >> "No Freaking Security".


    PH> Then why bother about blank SSH key passphrases at all? These keys
    PH> have to be regarded as compromised anyway.

    Then change them all & encrypt the new keys.

    Just because multiple related parts of a system are flawed, does not mean
    there's no point in fixing some of them. You have to start somewhere.

    --
    Richard Silverman
    res@qoxp.net


  17. Re: Force non-empty pass-phrase?

    mark schrieb:
    > On Thu, 27 Apr 2006 00:52:27 -0400, Richard E. Silverman wrote:
    >
    >>>>>>>"mark" == mark writes:

    >>
    >> mark> Does anybody know of a way to enforce a policy where ssh key
    >> mark> pass-phrases should not be empty? It is one of the "weaknesses"
    >> mark> of ssh as I see it that an administrator can't actually impose
    >> mark> this constraint on access to his own server.
    >>
    >>He can't, because it makes no sense. The server never sees the user's
    >>private key. It has no control over where or how the key is stored. It's
    >>like suggesting there's a lock out there that can "require" that you not
    >>keep the key in your pocket.

    >
    >
    > Richard, of course I realise that it doesn't "make sense" wrt to the
    > fundamental design of ssh. The pass-phrase is only pertinent to
    > unlocking the user's private key and that is that. But surely it does
    > make "make sense" that an administrator may have a personal opinion that
    > users should not be allowed to use empty pass-phrases on their keys?
    > What I am saying is that it has always seemed to me a bit of a
    > deficiency of ssh that an administrator can not actually enforce this
    > policy on users to whom he is granting access to his server?
    >
    > I guess it would be possible to write a script for root to traverse over
    > unix users client side home areas attempting to do some kind of
    > ssh-keygen operation on their keys and confirming that a pass-phrase is
    > prompted for? This doesn't address remote putty users etc, though.
    >


    I agree with you!
    I am adminstrator for serveral hundreds servers, and I can not
    enforce the users not to use encrypted keys. I would welcome an
    extension to the protocoll to ask the client if the key is encrypted or
    not. In an environment, e.g. intranet of an company like mine, where the
    users can not install other binary (hopefully) it would make sense.

    At the moment, the only method is to restrict the users to a central
    login server an to scan the keys, which is very time consuming.

  18. Re: Force non-empty pass-phrase?

    >>>>> "WT" == Wolfgang writes:

    WT> mark schrieb:
    >> On Thu, 27 Apr 2006 00:52:27 -0400, Richard E. Silverman wrote:
    >>>>>>>> "mark" == mark writes:
    >>>

    mark> Does anybody know of a way to enforce a policy where ssh key
    mark> pass-phrases should not be empty? It is one of the "weaknesses"
    mark> of ssh as I see it that an administrator can't actually impose
    mark> this constraint on access to his own server.
    >>> He can't, because it makes no sense. The server never sees the
    >>> user's private key. It has no control over where or how the key
    >>> is stored. It's like suggesting there's a lock out there that can
    >>> "require" that you not keep the key in your pocket.

    >> Richard, of course I realise that it doesn't "make sense" wrt to
    >> the fundamental design of ssh. The pass-phrase is only pertinent to
    >> unlocking the user's private key and that is that. But surely it
    >> does make "make sense" that an administrator may have a personal
    >> opinion that users should not be allowed to use empty pass-phrases
    >> on their keys? What I am saying is that it has always seemed to me
    >> a bit of a deficiency of ssh that an administrator can not actually
    >> enforce this policy on users to whom he is granting access to his
    >> server? I guess it would be possible to write a script for root to
    >> traverse over unix users client side home areas attempting to do
    >> some kind of ssh-keygen operation on their keys and confirming that
    >> a pass-phrase is prompted for? This doesn't address remote putty
    >> users etc, though.
    >>


    WT> I agree with you! I am adminstrator for serveral hundreds
    WT> servers, and I can not enforce the users not to use encrypted
    WT> keys. I would welcome an extension to the protocoll to ask the
    WT> client if the key is encrypted or not. In an environment,
    WT> e.g. intranet of an company like mine, where the users can not
    WT> install other binary (hopefully) it would make sense.

    If you're going to rely on people's inability to use other than provided
    software, what would make more sense is to modify the client to simply
    refuse to use plaintext keys, rather than clutter the protocol with an
    extension which does not increase security.

    --
    Richard Silverman
    res@qoxp.net


+ Reply to Thread