Method to customize SSH settings per user - SSH

This is a discussion on Method to customize SSH settings per user - SSH ; Hello all, (OpenSSH 3.4p1,3.8p1,4.0p1/ SuSE, Fedora) I'm a little stuck on the best way to go about solving a problem and currently it has lead me to ask this question (the fact that it is getting so complicated probably is ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Method to customize SSH settings per user

  1. Method to customize SSH settings per user

    Hello all,

    (OpenSSH 3.4p1,3.8p1,4.0p1/ SuSE, Fedora)

    I'm a little stuck on the best way to go about solving a problem and
    currently it has lead me to ask this question (the fact that it is
    getting so complicated probably is suggesting there is a better way for
    me to be going about it!)

    What I am hoping to do it create an account on a system which can only
    be accessed with keys (I want password authentication impossible).
    However I need other accounts on the system to be accessible with
    passwords. In the sshd_config file I need to have UsePAM set to yes
    which circumvents the PasswordAuthentication option. Has anyone ever
    tackled a problem such as this or know if it is even possible?

    What would be ideal is to have a .ssh/config file with
    PasswordAuthentication set to no, and have that override the global
    UsePAM setting...however it works the exact opposite (which makes
    sense).

    Any suggestions are much appreciated. Thanks for the help
    Chris


  2. Re: Method to customize SSH settings per user

    "krsyoung" writes:

    >Hello all,


    >(OpenSSH 3.4p1,3.8p1,4.0p1/ SuSE, Fedora)


    >I'm a little stuck on the best way to go about solving a problem and
    >currently it has lead me to ask this question (the fact that it is
    >getting so complicated probably is suggesting there is a better way for
    >me to be going about it!)


    >What I am hoping to do it create an account on a system which can only
    >be accessed with keys (I want password authentication impossible).
    >However I need other accounts on the system to be accessible with
    >passwords. In the sshd_config file I need to have UsePAM set to yes
    >which circumvents the PasswordAuthentication option. Has anyone ever
    >tackled a problem such as this or know if it is even possible?



    Just make sure that account has no password. Thus if they try to use
    password they cannot ( or make sure that the password is unknown to them)

    >What would be ideal is to have a .ssh/config file with
    >PasswordAuthentication set to no, and have that override the global
    >UsePAM setting...however it works the exact opposite (which makes
    >sense).


    >Any suggestions are much appreciated. Thanks for the help
    >Chris



  3. Re: Method to customize SSH settings per user


    "krsyoung" wrote in message
    news:1137718148.885008.273700@g14g2000cwa.googlegr oups.com...
    > Hello all,
    >
    > (OpenSSH 3.4p1,3.8p1,4.0p1/ SuSE, Fedora)
    >
    > I'm a little stuck on the best way to go about solving a problem and
    > currently it has lead me to ask this question (the fact that it is
    > getting so complicated probably is suggesting there is a better way for
    > me to be going about it!)
    >
    > What I am hoping to do it create an account on a system which can only
    > be accessed with keys (I want password authentication impossible).
    > However I need other accounts on the system to be accessible with
    > passwords. In the sshd_config file I need to have UsePAM set to yes
    > which circumvents the PasswordAuthentication option. Has anyone ever
    > tackled a problem such as this or know if it is even possible?


    Edit the /etc/passwd, or in systems with shadow passwords, /etc/shadow file
    to set the password field to be "*locked*" for that account. The "*" is an
    invalid character for encrypted passwords: *nothing* encrypts to match
    anything containing "*". This also prevents users from resetting that
    password, except for the root user.

    Doing this for NIS or LDAP setups is left as an exercise for the reader, but
    I suggest staying the heck out of this.

    > What would be ideal is to have a .ssh/config file with
    > PasswordAuthentication set to no, and have that override the global
    > UsePAM setting...however it works the exact opposite (which makes
    > sense).
    >
    > Any suggestions are much appreciated. Thanks for the help
    > Chris
    >




  4. Re: Method to customize SSH settings per user

    On 2006-01-20, krsyoung wrote:
    > (OpenSSH 3.4p1,3.8p1,4.0p1/ SuSE, Fedora)

    [...]
    > What I am hoping to do it create an account on a system which can only
    > be accessed with keys (I want password authentication impossible).
    > However I need other accounts on the system to be accessible with
    > passwords. In the sshd_config file I need to have UsePAM set to yes
    > which circumvents the PasswordAuthentication option. Has anyone ever
    > tackled a problem such as this or know if it is even possible?


    Configure PAM to do it. You want the auth stack to deny any accounts
    that aren't allowed to use PasswordAuthentication, but this will still
    allow non-password authentications (you probably want to disable all but
    RSAAuthentication in sshd_config).

    One way to do this is with pam_listfile. Something like this ought to
    work (untested, beware line wrap):

    auth required pam_listfile.so \
    onerr=fail item=user sense=allow file=/etc/passwordallowedusers

    Any users not listed in /etc/passwordallowedusers will not be able to
    authenticate via PAM. It will still allow other users to authenticate
    purely via ssh and as long as the other PAM stacks (account, session)
    succeed then they'll still be allowed to log in.

    If it's easier from an admin POV, you could invert the sense of the
    listfile check and list only users who are not allowed to authenticate
    with passwords.

    --
    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.

  5. Re: Method to customize SSH settings per user

    On 2006-01-20, Unruh wrote:
    >>What I am hoping to do it create an account on a system which can only
    >>be accessed with keys (I want password authentication impossible).

    >
    > Just make sure that account has no password.


    That's very bad idea. Even assuming you have PermitEmptyPasswords=no
    in your sshd_config, if *anyone* can get to *any* other service (telnet,
    ftp, console, whatever) they'll be allowed to log in without any password
    at all.

    And even if that's not possible right now, it's an accident waiting to
    happen: if at any time in the future a service is added or the sshd_config
    is changed, the accounts could be left wide open to anyone, not just the
    owners of the accounts.

    > ( or make sure that the password is unknown to them)


    Now that's a reasonable approach, as long as the password is strong
    enough and not recorded anywhere. I occasionally use something like
    "openssl rand -base64 15" to generate throwaway passwords for this kind
    of thing.[1]

    A much better alternative is, as Nico suggested, to set the password
    string to something that's not a valid encrypted password string (but
    not the "locked account" string, which is "!!" on most Linuxes).

    [1] Purists will note that this doesn't use all of the available
    characters in a password string, but even an 8-character password
    generated this way still has 48 bits of entropy which is more than a
    typical human-generated password.

    --
    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.

  6. Re: Method to customize SSH settings per user

    Wow, 20 minutes and 3 solutions...can't beat that. My only beef, that
    NIS & LDAP comment was 3 months late :P

    Thanks for the help everyone, truly amazing. I'll follow up with the
    final implementation.

    Chris


  7. Re: Method to customize SSH settings per user

    Darren Tucker writes:

    >On 2006-01-20, Unruh wrote:
    >>>What I am hoping to do it create an account on a system which can only
    >>>be accessed with keys (I want password authentication impossible).

    >>
    >> Just make sure that account has no password.


    >That's very bad idea. Even assuming you have PermitEmptyPasswords=no
    >in your sshd_config, if *anyone* can get to *any* other service (telnet,
    >ftp, console, whatever) they'll be allowed to log in without any password
    >at all.


    Oh come on. No password does NOT mean an empty password entry in
    /etc/passwd . That is ALL passwords, not No password.
    If you need it spelled out, to make sure that the account has NO password,
    make sure that password entry in /etc/passwd is invalid. A bunch of stars
    for example. Or the word Invalid.


    >And even if that's not possible right now, it's an accident waiting to
    >happen: if at any time in the future a service is added or the sshd_config
    >is changed, the accounts could be left wide open to anyone, not just the
    >owners of the accounts.


    >> ( or make sure that the password is unknown to them)


    >Now that's a reasonable approach, as long as the password is strong
    >enough and not recorded anywhere. I occasionally use something like
    >"openssl rand -base64 15" to generate throwaway passwords for this kind
    >of thing.[1]


    >A much better alternative is, as Nico suggested, to set the password
    >string to something that's not a valid encrypted password string (but
    >not the "locked account" string, which is "!!" on most Linuxes).


    >[1] Purists will note that this doesn't use all of the available
    >characters in a password string, but even an 8-character password
    >generated this way still has 48 bits of entropy which is more than a
    >typical human-generated password.


    >--
    >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.


  8. Re: Method to customize SSH settings per user


    "Unruh" wrote in message
    news:dqppo7$gr3$1@nntp.itservices.ubc.ca...
    > Darren Tucker writes:
    >
    >>On 2006-01-20, Unruh wrote:
    >>>>What I am hoping to do it create an account on a system which can only
    >>>>be accessed with keys (I want password authentication impossible).
    >>>
    >>> Just make sure that account has no password.

    >
    >>That's very bad idea. Even assuming you have PermitEmptyPasswords=no
    >>in your sshd_config, if *anyone* can get to *any* other service (telnet,
    >>ftp, console, whatever) they'll be allowed to log in without any password
    >>at all.

    >
    > Oh come on. No password does NOT mean an empty password entry in
    > /etc/passwd . That is ALL passwords, not No password.


    That's commonly referred to as "no password". And no, it's not "all
    passwords". I suggest you go try setting an account on a test system with no
    password field and see if it accepts any password other than simply hitting
    the "enter" key. And yes, spelling it out for a newbie is reasonable.

    > If you need it spelled out, to make sure that the account has NO password,
    > make sure that password entry in /etc/passwd is invalid. A bunch of stars
    > for example. Or the word Invalid.


    Agreed. I use "*locked*" because that's known to work well.



  9. Re: Method to customize SSH settings per user

    Darren Tucker wrote:

    > On 2006-01-20, krsyoung wrote:
    >> (OpenSSH 3.4p1,3.8p1,4.0p1/ SuSE, Fedora)

    > [...]
    >> What I am hoping to do it create an account on a system which can only
    >> be accessed with keys (I want password authentication impossible).
    >> However I need other accounts on the system to be accessible with
    >> passwords. In the sshd_config file I need to have UsePAM set to yes
    >> which circumvents the PasswordAuthentication option. Has anyone ever
    >> tackled a problem such as this or know if it is even possible?

    >
    > Configure PAM to do it. You want the auth stack to deny any accounts
    > that aren't allowed to use PasswordAuthentication, but this will still
    > allow non-password authentications (you probably want to disable all but
    > RSAAuthentication in sshd_config).
    >
    > One way to do this is with pam_listfile. Something like this ought to
    > work (untested, beware line wrap):
    >
    > auth required pam_listfile.so \
    > onerr=fail item=user sense=allow file=/etc/passwordallowedusers
    >


    Sanity check, please. The "no [known to user] password" options don't work
    in some cases because some people do need sudo access (and I am reluctant
    to use NOPASSWD). The idea above sounds like a way I can address this.

    Right now, both sshd and sudo files in /etc/pam.d refer to system-auth. Am
    I correct that I'd want to:

    1. Make the above change in system-auth, and
    2. create an alternative to system-auth w/o this change, and
    3. have sudo refer to the alternative file?

    Yes?

    Thanks...

    Andrew


  10. Re: Method to customize SSH settings per user

    On 2006-01-24, Andrew Gideon wrote:
    > Sanity check, please. The "no [known to user] password" options don't work
    > in some cases because some people do need sudo access (and I am reluctant
    > to use NOPASSWD). The idea above sounds like a way I can address this.
    >
    > Right now, both sshd and sudo files in /etc/pam.d refer to system-auth. Am
    > I correct that I'd want to:
    >
    > 1. Make the above change in system-auth, and
    > 2. create an alternative to system-auth w/o this change, and
    > 3. have sudo refer to the alternative file?


    Sounds right. You probably just want to copy the original system-auth to
    sudo. Be aware that some systems will overwrite system-auth, though.

    --
    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