Please explain OpenSSH double authentication lack - SSH

This is a discussion on Please explain OpenSSH double authentication lack - SSH ; Hi, I search for a lot of time, but I haven't found any persuasive reason why OpenSSH doesn't permit to require two authentication mechanisms (PubKey _and_ passowrd), as Tectia, Van Dyke, etc... do. It's only another option, but it's seems ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Please explain OpenSSH double authentication lack

  1. Please explain OpenSSH double authentication lack

    Hi,
    I search for a lot of time, but I haven't found any persuasive reason
    why OpenSSH doesn't permit to require two authentication mechanisms
    (PubKey _and_ passowrd), as Tectia, Van Dyke, etc... do.

    It's only another option, but it's seems to be a matter of philosophy.

  2. Re: Please explain OpenSSH double authentication lack

    >>>>> "brontolo" == brontolo writes:

    brontolo> Hi, I search for a lot of time, but I haven't found any
    brontolo> persuasive reason why OpenSSH doesn't permit to require two
    brontolo> authentication mechanisms (PubKey _and_ passowrd), as
    brontolo> Tectia, Van Dyke, etc... do.

    brontolo> It's only another option, but it's seems to be a matter of
    brontolo> philosophy.

    I believe this feature is in the upcoming release; Darren can confirm or deny.

    --
    Richard Silverman
    res@qoxp.net


  3. Re: Please explain OpenSSH double authentication lack

    brontolo wrote:
    > Hi,
    > I search for a lot of time, but I haven't found any persuasive reason
    > why OpenSSH doesn't permit to require two authentication mechanisms
    > (PubKey _and_ passowrd), as Tectia, Van Dyke, etc... do.
    >
    > It's only another option, but it's seems to be a matter of philosophy.


    Silly question but why would you want to do this? One level of
    authentication should be more than enough. Especially if using pubkey
    with an encrypted private key. It effectively does the same thing. You
    need to have both the passphrase and the key to use it.

  4. Re: Please explain OpenSSH double authentication lack

    Chuck wrote:
    > brontolo wrote:
    >> Hi,
    >> I search for a lot of time, but I haven't found any persuasive
    >> reason why OpenSSH doesn't permit to require two authentication
    >> mechanisms (PubKey _and_ passowrd), as Tectia, Van Dyke, etc... do.
    >>
    >> It's only another option, but it's seems to be a matter of
    >> philosophy.

    >
    > Silly question but why would you want to do this? One level of
    > authentication should be more than enough. Especially if using pubkey
    > with an encrypted private key. It effectively does the same thing. You
    > need to have both the passphrase and the key to use it.


    Lots of reasons: if users will be SSH-ing in from of-site, they need either
    their password or their SSH key or something else. If that is stolen, for
    example by keystroke monitoring or by someone stealing their laptop, then
    you don't want whoever stole it to have full access with that singly stolen
    key.

    SSH keys are useful this way, since they *should* be set up to require a
    passphrase, but there's no way for the server to know that anyone actually
    did this. Way, way, way too many users simply use passphraseless keys, which
    are far too easy to steal. (If your local network supports NFS, I urge you
    to take a look in home directories for all the passphraseless keys: it's
    always embarassing!) So enforcing another authentication method, such as
    S/Key, can be very helpful.



  5. Re: Please explain OpenSSH double authentication lack

    Nico Kadel-Garcia wrote:
    > Chuck wrote:
    >> brontolo wrote:
    >>> Hi,
    >>> I search for a lot of time, but I haven't found any persuasive
    >>> reason why OpenSSH doesn't permit to require two authentication
    >>> mechanisms (PubKey _and_ passowrd), as Tectia, Van Dyke, etc... do.
    >>>
    >>> It's only another option, but it's seems to be a matter of
    >>> philosophy.

    >> Silly question but why would you want to do this? One level of
    >> authentication should be more than enough. Especially if using pubkey
    >> with an encrypted private key. It effectively does the same thing. You
    >> need to have both the passphrase and the key to use it.

    >
    > Lots of reasons: if users will be SSH-ing in from of-site, they need either
    > their password or their SSH key or something else. If that is stolen, for
    > example by keystroke monitoring or by someone stealing their laptop, then
    > you don't want whoever stole it to have full access with that singly stolen
    > key.
    >
    > SSH keys are useful this way, since they *should* be set up to require a
    > passphrase, but there's no way for the server to know that anyone actually
    > did this. Way, way, way too many users simply use passphraseless keys, which
    > are far too easy to steal. (If your local network supports NFS, I urge you
    > to take a look in home directories for all the passphraseless keys: it's
    > always embarassing!) So enforcing another authentication method, such as
    > S/Key, can be very helpful.
    >
    >


    Understood.

    You should be able to enforce the use of encrypted private keys through
    policy management. Even just something that scans the HD when they
    connect to your network for id_[rd]sa files and looks for the string
    ENCRYPTED.

  6. Re: Please explain OpenSSH double authentication lack

    Chuck wrote:

    > You should be able to enforce the use of encrypted private keys
    > through policy management. Even just something that scans the HD when
    > they connect to your network for id_[rd]sa files and looks for the
    > string ENCRYPTED.


    Well, yes. But when I've done that, I've actually gotten yelled at. For
    doing tasks not on my tasklist, but the real reason was that people who
    found it inconvenient, even if I had helped them set up Pageant to manage
    their keys.

    It's also very difficult to scan directories that are not NFS or CIFS
    published: laptops are the worst offenders, where people simply leave
    unlocked keys, lists of passwords, etc. even while they go on the road,
    where thieves and crackers will have physical access. Then there's the
    frequent, unannounced publication of the C: drive as the share C$ on Windows
    XP Pro: I've used that gaping hole to quietly probe a problem machine, and
    to demonstrate the risks of having no Administrator password. And the same
    people who use passphraseless SSH keys are the same ones likely to have no
    Administrator password. "We have firewall! We trust our coworkers! They
    signed a non-disclosure agreement! Etc., etc., etc."



  7. Re: Please explain OpenSSH double authentication lack

    Nico Kadel-Garcia wrote:
    > Chuck wrote:
    >
    >> You should be able to enforce the use of encrypted private keys
    >> through policy management. Even just something that scans the HD when
    >> they connect to your network for id_[rd]sa files and looks for the
    >> string ENCRYPTED.

    >
    > Well, yes. But when I've done that, I've actually gotten yelled at. For
    > doing tasks not on my tasklist, but the real reason was that people who
    > found it inconvenient, even if I had helped them set up Pageant to manage
    > their keys.
    >
    > It's also very difficult to scan directories that are not NFS or CIFS
    > published: laptops are the worst offenders, where people simply leave
    > unlocked keys, lists of passwords, etc. even while they go on the road,
    > where thieves and crackers will have physical access. Then there's the
    > frequent, unannounced publication of the C: drive as the share C$ on Windows
    > XP Pro: I've used that gaping hole to quietly probe a problem machine, and
    > to demonstrate the risks of having no Administrator password. And the same
    > people who use passphraseless SSH keys are the same ones likely to have no
    > Administrator password. "We have firewall! We trust our coworkers! They
    > signed a non-disclosure agreement! Etc., etc., etc."
    >
    >


    Our company runs a winscript file whenever you log on to the network to
    do some drive mappings and stuff like that. It shouldn't be too
    difficult to add a check that the private key is encrypted.

  8. Re: Please explain OpenSSH double authentication lack

    >>>>> "Chuck" == Chuck writes:

    Chuck> Nico Kadel-Garcia wrote:
    >> Chuck wrote:
    >>> You should be able to enforce the use of encrypted private keys
    >>> through policy management. Even just something that scans the HD
    >>> when they connect to your network for id_[rd]sa files and looks
    >>> for the string ENCRYPTED.

    >> Well, yes. But when I've done that, I've actually gotten yelled
    >> at. For doing tasks not on my tasklist, but the real reason was
    >> that people who found it inconvenient, even if I had helped them
    >> set up Pageant to manage their keys.
    >>
    >> It's also very difficult to scan directories that are not NFS or
    >> CIFS published: laptops are the worst offenders, where people
    >> simply leave unlocked keys, lists of passwords, etc. even while
    >> they go on the road, where thieves and crackers will have physical
    >> access. Then there's the frequent, unannounced publication of the
    >> C: drive as the share C$ on Windows XP Pro: I've used that gaping
    >> hole to quietly probe a problem machine, and to demonstrate the
    >> risks of having no Administrator password. And the same people who
    >> use passphraseless SSH keys are the same ones likely to have no
    >> Administrator password. "We have firewall! We trust our coworkers!
    >> They signed a non-disclosure agreement! Etc., etc., etc."
    >>
    >>


    Chuck> Our company runs a winscript file whenever you log on to the
    Chuck> network to do some drive mappings and stuff like that. It
    Chuck> shouldn't be too difficult to add a check that the private key
    Chuck> is encrypted.

    The private key file does not have to be in the canonical place.

    --
    Richard Silverman
    res@qoxp.net


  9. Re: Please explain OpenSSH double authentication lack

    Chuck wrote:
    > brontolo wrote:
    >> Hi,
    >> I search for a lot of time, but I haven't found any persuasive reason
    >> why OpenSSH doesn't permit to require two authentication mechanisms
    >> (PubKey _and_ passowrd), as Tectia, Van Dyke, etc... do.
    >>
    >> It's only another option, but it's seems to be a matter of philosophy.

    >
    > Silly question but why would you want to do this? One level of
    > authentication should be more than enough. Especially if using pubkey
    > with an encrypted private key. It effectively does the same thing. You
    > need to have both the passphrase and the key to use it.


    I could agree with you on general argument, but there is some problem in
    including an option to require more than one authentication mechanism?
    Nobody will be force to use it, but if somebody want, why not?

  10. Re: Please explain OpenSSH double authentication lack

    Chuck wrote:
    > Our company runs a winscript file whenever you log on to the network
    > to do some drive mappings and stuff like that. It shouldn't be too
    > difficult to add a check that the private key is encrypted.


    We could play "Why Don't You, Yes But" all day. A simple script to check for
    obvious key names in standard locations their home directory makes complete
    sense: An irritating or irritated user can then keep their key files
    somewhere else, such as their "C:\temp" directory, and the problem goes
    around again.



  11. Re: Please explain OpenSSH double authentication lack

    On 2006-07-25, Richard E. Silverman wrote:
    >>>>>> "brontolo" == brontolo writes:

    >
    > brontolo> Hi, I search for a lot of time, but I haven't found any
    > brontolo> persuasive reason why OpenSSH doesn't permit to require two
    > brontolo> authentication mechanisms (PubKey _and_ passowrd), as
    > brontolo> Tectia, Van Dyke, etc... do.
    >
    > brontolo> It's only another option, but it's seems to be a matter of
    > brontolo> philosophy.
    >
    > I believe this feature is in the upcoming release; Darren can confirm or deny.


    There's an open enhancement request[1] for it (with some code) but needs
    some more work. It's not in the current development tree and is unlikely
    to be in the next release.

    [1] http://bugzilla.mindrot.org/show_bug.cgi?id=983

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

+ Reply to Thread