Preventing Auto-Login - SSH

This is a discussion on Preventing Auto-Login - SSH ; Folks, We have some devious developers that use ssh between two Solaris servers. They run ssh-keygen -t rsa etc etc and set up their auto login between the two servers. Is there a setting in /etc/ssh/sshd_config that I can change ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Preventing Auto-Login

  1. Preventing Auto-Login

    Folks,

    We have some devious developers that use ssh between two Solaris
    servers.

    They run ssh-keygen -t rsa etc etc and set up their auto login between
    the two servers.

    Is there a setting in /etc/ssh/sshd_config that I can change to ALWAYS
    ask for a password and prevent ssh from using public/private key
    authentication ?

    We'd ideally like to be able to rotate the passwords after the
    developers leave and not leave this potiental for a back door into our
    systems. Disabling ssh is not an option as we ( root users ) use it
    all the time..

    Bit new to this so please bear with me.

    Thanks.

    c

  2. Re: Preventing Auto-Login

    On Tue, 15 Jul 2008 08:53:18 -0700, c wrote:

    > Folks,
    >
    > We have some devious developers that use ssh between two Solaris
    > servers.
    >
    > They run ssh-keygen -t rsa etc etc and set up their auto login between
    > the two servers.
    >
    > Is there a setting in /etc/ssh/sshd_config that I can change to ALWAYS
    > ask for a password and prevent ssh from using public/private key
    > authentication ?
    >
    > We'd ideally like to be able to rotate the passwords after the
    > developers leave and not leave this potiental for a back door into our
    > systems. Disabling ssh is not an option as we ( root users ) use it all
    > the time..


    For OpenSSH I believe that one can add an entry to the
    sshd_config file to control this.

    Are you positive that you want to do this though? Password
    authentication is far less secure than public key authentication, and
    when your developers leave you can remove from your system the public
    they used in order to log in passwordless.


  3. Re: Preventing Auto-Login

    c writes:

    > Folks,
    >
    > We have some devious developers that use ssh between two Solaris
    > servers.
    >
    > They run ssh-keygen -t rsa etc etc and set up their auto login between
    > the two servers.
    >
    > Is there a setting in /etc/ssh/sshd_config that I can change to ALWAYS
    > ask for a password and prevent ssh from using public/private key
    > authentication ?
    >
    > We'd ideally like to be able to rotate the passwords after the
    > developers leave and not leave this potiental for a back door into our
    > systems. Disabling ssh is not an option as we ( root users ) use it
    > all the time..
    >
    > Bit new to this so please bear with me.


    You are attempting to implement a technical control on a people issue,
    and actually may end up making things less secure in the process. :-)

    The good news is that these developers aren't weakening your security,
    more than likely.

    Key based auth is actually more secure than password auth as it
    resists brute force attacks much better. If you've checked log files
    for any sshd on the internet, you know that brute force attacks are
    out there in force!

    I believe your primary concern should instead be sure that these
    developers have protected their private keys with a passphrase that's
    not trivially broken, and that their keys are not world readable
    (though I'm not sure if openssh will even use such keys).

    This brings up the interesting question of whether there are tools to
    audit those.

    By the way, I work on a hgihly secured system for a client, and that
    one WONT't allow anything but key based auth. Password based auth is
    disabled by administrative choice. Key based auth is where it's
    at.


    --
    Todd H.
    http://www.toddh.net/

  4. Re: Preventing Auto-Login

    On 15 Jul, 19:39, comph...@toddh.net (Todd H.) wrote:

    > Key based auth is actually more secure than password auth as it
    > resists brute force attacks much better. * If you've checked log files
    > for any sshd on the internet, *you know that brute force attacks are
    > out there in force!


    Survey says.... maybe not. Many lazy programmers use passphrase-less
    SSH keys for all sorts of inappropriate system access. And the
    behavior of ssh-keygen to allow such passwords, by default, by simply
    refusing to type in a passphrase contributes heavily to the problem,
    and to the attitude, that merely using SSH keys makes things secure.

    Having an unprotected SSH key is as bad as taping your password under
    your keyboard, and they're much easier to steal off of backup tapes or
    NFS shares. If you're somewhat aggressive about your site security,
    it's a good policy to check user's .ssh/ directories for password-free
    keys.

  5. Re: Preventing Auto-Login

    Nico Kadel-Garcia writes:

    > On 15 Jul, 19:39, comph...@toddh.net (Todd H.) wrote:
    >
    >> Key based auth is actually more secure than password auth as it
    >> resists brute force attacks much better. * If you've checked log files
    >> for any sshd on the internet, *you know that brute force attacks are
    >> out there in force!

    >
    > Survey says.... maybe not. Many lazy programmers use passphrase-less
    > SSH keys for all sorts of inappropriate system access. And the
    > behavior of ssh-keygen to allow such passwords, by default, by simply
    > refusing to type in a passphrase contributes heavily to the problem,
    > and to the attitude, that merely using SSH keys makes things secure.
    >
    > Having an unprotected SSH key is as bad as taping your password under
    > your keyboard, and they're much easier to steal off of backup tapes or
    > NFS shares. If you're somewhat aggressive about your site security,
    > it's a good policy to check user's .ssh/ directories for password-free
    > keys.


    Which, if you read the rest of my post other than what you trimmed and
    quoted, you'd see I agree with as well.


    --
    Todd H.
    http://www.toddh.net/

  6. Re: Preventing Auto-Login

    On 16 Jul, 05:19, comph...@toddh.net (Todd H.) wrote:
    > Nico Kadel-Garcia writes:
    > > On 15 Jul, 19:39, comph...@toddh.net (Todd H.) wrote:

    >
    > >> Key based auth is actually more secure than password auth as it
    > >> resists brute force attacks much better. * If you've checked log files
    > >> for any sshd on the internet, *you know that brute force attacks are
    > >> out there in force!

    >
    > > Survey says.... maybe not. Many lazy programmers use passphrase-less
    > > SSH keys for all sorts of inappropriate system access. And the
    > > behavior of ssh-keygen to allow such passwords, by default, by simply
    > > refusing to type in a passphrase contributes heavily to the problem,
    > > and to the attitude, that merely using SSH keys makes things secure.

    >
    > > Having an unprotected SSH key is as bad as taping your password under
    > > your keyboard, and they're much easier to steal off of backup tapes or
    > > NFS shares. If you're somewhat aggressive about your site security,
    > > it's a good policy to check user's .ssh/ directories for password-free
    > > keys.

    >
    > Which, if you read the rest of my post other than what you trimmed and
    > quoted, you'd see I agree with as well.
    >
    > --
    > Todd H.http://www.toddh.net/


    I'm sorry, Todd, for missing the details of your post. I do agree with
    you on most of it as well.

    But you commented on weak keys: I will stand by my concern over the
    existing, common practice of using *no* passphrase on keys. It drives
    me nuts, and is one of the most common mistakes. I've had an
    unfortunate security conversation with several Sourceforge
    contributors about *NOT* storing their password free keys on NFS
    shares. The rampant mishandling of SSH keys, and the storage of HTTP/
    HTTPS/svnserve keys in plain text locally, are someof my big problems
    with Subversion itself as a source control system, and why I'm
    studying up on git right now.

    You also missed that 'not readable' for SSH keys is nowhere enough
    protection. NFS shares of home directories are pretty trivially
    readable by anyone, and backup tapes can and do get perused by others.
    This sort of thing is why I'm more eager than ever to pursue single-
    sign-on Kerberized authentication, for SSH users especially. There's a
    Putty variant that supports this now, and it's scheduled to go into
    the next Putty release if I remember Simon Tatham's comments on this
    correctly. And I'm pursuing it for RHEL use.

  7. Re: Preventing Auto-Login

    Todd H. ha scritto:
    > c writes:
    >
    > You are attempting to implement a technical control on a people issue,
    > and actually may end up making things less secure in the process. :-)
    >
    > The good news is that these developers aren't weakening your security,
    > more than likely.
    >
    > Key based auth is actually more secure than password auth as it
    > resists brute force attacks much better. If you've checked log files
    > for any sshd on the internet, you know that brute force attacks are
    > out there in force!
    >
    > I believe your primary concern should instead be sure that these
    > developers have protected their private keys with a passphrase that's
    > not trivially broken, and that their keys are not world readable
    > (though I'm not sure if openssh will even use such keys).
    >
    > This brings up the interesting question of whether there are tools to
    > audit those.
    >
    > By the way, I work on a hgihly secured system for a client, and that
    > one WONT't allow anything but key based auth. Password based auth is
    > disabled by administrative choice. Key based auth is where it's
    > at.


    You forgot that system password can be locked (even automatically on
    expire time) using standard user-management tools.
    Public key must be removed or renamed manually.

    The problem can be avoided if OpenSSH will implement a feature that
    optionally can require _both_ key and password authentication, as Tectia
    or F-Secure ssh implementations do.

  8. Re: Preventing Auto-Login

    On 16 Jul, 09:24, brontolo wrote:
    > Todd H. ha scritto:
    >
    >
    >
    > > c writes:

    >
    > > You are attempting to implement a technical control on a people issue,
    > > and actually may end up making things less secure in the process. *:-)

    >
    > > The good news is that these developers aren't weakening your security,
    > > more than likely.

    >
    > > Key based auth is actually more secure than password auth as it
    > > resists brute force attacks much better. * If you've checked log files
    > > for any sshd on the internet, *you know that brute force attacks are
    > > out there in force!

    >
    > > I believe your primary concern should instead be sure that these
    > > developers have protected their private keys with a passphrase that's
    > > not trivially broken, and that their keys are not world readable
    > > (though I'm not sure if openssh will even use such keys).

    >
    > > This brings up the interesting question of whether there are tools to
    > > audit those.

    >
    > > By the way, I work on a hgihly secured system for a client, and that
    > > one WONT't allow anything but key based auth. *Password based auth is
    > > disabled by administrative choice. * *Key based auth is where it's
    > > at.

    >
    > You forgot that system password can be locked (even automatically on
    > expire time) using standard user-management tools.
    > Public key must be removed or renamed manually.
    >
    > The problem can be avoided if OpenSSH will implement a feature that
    > optionally can require _both_ key and password authentication, as Tectia
    > or F-Secure ssh implementations do.


    Have you successfully used this?

    There are plenty of procedures, such as rsync over SSH based backup
    procedures and Subversion access, that do require unattended access.
    It's the sort of thing that makes me wish that chroot cages had been
    properly implemented for OpenSSH 5. (All chroot users having the same,
    shared chroot cage is fairly nutty: the paches to support per-user
    chroot cages have been around for years, and I'm confused why those
    weren't used.)

  9. Re: Preventing Auto-Login

    Nico Kadel-Garcia ha scritto:
    > Have you successfully used this?


    Oh, yes! I run for years sshd2 from SSH Communication on several
    servers, including one used for a commercial web hosting service.

    > There are plenty of procedures, such as rsync over SSH based backup
    > procedures and Subversion access, that do require unattended access.
    > It's the sort of thing that makes me wish that chroot cages had been
    > properly implemented for OpenSSH 5. (All chroot users having the same,
    > shared chroot cage is fairly nutty: the paches to support per-user
    > chroot cages have been around for years, and I'm confused why those
    > weren't used.)


    Tectia offers specific sub configuration on per-user or per-host basis.
    So, you can allow a batch user to access only with key (or only with
    password) enforcing other restriction.

  10. Re: Preventing Auto-Login

    On Tue, 15 Jul 2008 18:14:27 -0700 (PDT) Nico Kadel-Garcia wrote:
    | On 15 Jul, 19:39, comph...@toddh.net (Todd H.) wrote:
    |
    |> Key based auth is actually more secure than password auth as it
    |> resists brute force attacks much better. ? If you've checked log files
    |> for any sshd on the internet, ?you know that brute force attacks are
    |> out there in force!
    |
    | Survey says.... maybe not. Many lazy programmers use passphrase-less
    | SSH keys for all sorts of inappropriate system access. And the
    | behavior of ssh-keygen to allow such passwords, by default, by simply
    | refusing to type in a passphrase contributes heavily to the problem,
    | and to the attitude, that merely using SSH keys makes things secure.
    |
    | Having an unprotected SSH key is as bad as taping your password under
    | your keyboard, and they're much easier to steal off of backup tapes or
    | NFS shares. If you're somewhat aggressive about your site security,
    | it's a good policy to check user's .ssh/ directories for password-free
    | keys.

    Maybe more people would do this if the agent were easier to work with.
    I tried it several years ago and it really just didn't work right. No
    one helped, so I gave up on it. Biggest issue (but not the only one)
    was making sure each ssh client could find the agent. Something better
    than an environment variable is needed.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  11. Re: Preventing Auto-Login

    c writes:
    >We'd ideally like to be able to rotate the passwords after the
    >developers leave and not leave this potiental for a back door into our
    >systems.


    In that case I would, if I were you, focus on the issue of access after the
    developers leave.

    For that, nothing beats deleting their accounts. When people leave, to avoid
    having them log in to your computers, delete their accounts.

    Note that you can delete the account by removing the line from /etc/passwd
    without deleting its home directory, if you're concerned that there might be
    valuable source code which they forgot to check in, etc.

    But I suspect from your phrasing that you might have group accounts with
    passwords known to multiple people. I think that this is the problem here.
    Each account should have one user, only. When that person leaves, rather than
    changing the password and giving the account to someone else, the account
    should be deleted.

    It's easy and cheap to create and delete accounts. It's difficult to manage
    multi-user accounts.

  12. Kerberos in PuTTY (was: Re: Preventing Auto-Login)

    Last month, Nico Kadel-Garcia wrote:
    > This sort of thing is why I'm more eager than ever to pursue single-
    > sign-on Kerberized authentication, for SSH users especially. There's a
    > Putty variant that supports this now, and it's scheduled to go into
    > the next Putty release if I remember Simon Tatham's comments on this
    > correctly.


    Nico, you may be interested to hear that the Kerberos patch we've
    been polishing was committed into the PuTTY source control
    repository yesterday, and last night's nightly build completed
    successfully. So the current development snapshots should now
    support Kerberos, if you're lucky. Testing and comments would be
    welcome!
    --
    Simon Tatham "_shin_, n. An ingenious device for
    finding tables and chairs in the dark."

+ Reply to Thread