How to PREVENT a user from logging in through SSH

Discussion in 'Linux Networking' started by Ignoramus10392, Apr 7, 2008.

  1. Given prevalence of SSH dictionary attacks, I want to fortify my
    systems a little.

    I have several local (inside the house) users who I do NOT want to be
    able to log on from outside via ssh.

    I would like to disable any remote SSH logins for these users.

    How can I do that?

    Ignoramus10392, Apr 7, 2008
    1. Advertisements

  2. man 5 sshd_config
    Look at the AllowUsers / DenyUsers entries
    Peter Ludikovsky, Apr 7, 2008
    1. Advertisements

  3. Looks great to me. Thanks. I assume that if I say AllowUsers
    ....,root,... then, on conjunctions with PermitRootLogin
    without-password the passworded root login will not be allowed.

    I will try to verify everything.

    Ignoramus10392, Apr 7, 2008
  4. Security-wise it would be better to say "PermitRootLogin no" and
    "su"||"sudo" when needed. Also, setting "PasswordAuthentication no" and
    using Public Key Authentication is a good idea.

    Peter Ludikovsky, Apr 7, 2008
  5. Thanks. It worked fine. I have permitrootlogin without-password.

    I do need from time to time to perform root tasks from scripts, for
    example restarting named after DNS zone files update. I cannot fully
    disable root login, though not letting passworded root logins is a
    good idea which I already follow.

    Setting PasswordAuthentication to no seems like a very dangerous idea
    that can leave me stranded.

    Ignoramus10392, Apr 7, 2008
  6. Ignoramus10392

    Keith Keller Guest

    That is what su and sudo are for.

    Keith Keller, Apr 7, 2008
  7. Ignoramus10392

    Unruh Guest

    You did not understand him. Disallow root logins. Then you can get in as
    yourself and then su or sudo to root.
    If you put yourself into the sudo list then you could do a passwordless
    root login to yourself, and run the script which has a sudo in it to allow
    root to do the things it needs to do. You can also make sure that sudo only
    allows a few commands to be done in that way.

    Unruh, Apr 7, 2008
  8. I thought that both su and sudo require the user to enter a password?

    Ignoramus10392, Apr 7, 2008
  9. automatically from a script?
    I guess I was mistaken, but I thought that both sudo and su require me
    to enter some kind of password (mine or root's). Is that wrong?

    Ignoramus10392, Apr 7, 2008
  10. su does requires the password of the user you are switching to (unless
    you're root already). sudo *normally* requires the password of the
    user who invokes it as a additional security measure but can be
    configured to not require it. I would regard setting up a utility
    account with NOPASSWORD sudo privileges as more secure than letting
    root log directly in via SSH, as you can limit the utility account
    to be able to do as root only the things you list in sudo.

    Christopher Mattern

    Thank you for noticing this new notice
    Your noticing it has been noted
    And will be reported to the authorities
    Chris Mattern, Apr 7, 2008
  11. Ignoramus10392

    Simon Tatham Guest might be useful to

    It's roughly equivalent to setting up a setuid program permitting a
    specified set of users to request a specific service of root (or
    someone else), except that it's generally more secure than setuid
    programs since it goes through a daemon to avoid passing through
    arbitrary malicious process context.

    Restarting named is just the sort of thing it'd be ideal for. In
    fact I use it for that myself.
    Simon Tatham, Apr 7, 2008
  12. Ignoramus10392

    Todd H. Guest

    That's an orthogonal question to the whole ssh discussion if your
    script is executing on the local box.

    If you need to remotely do things on another box logging in a root
    with ssh and avoiding any password entry, doing public key auth to a
    role account (e.g. myscriptrunner as an account name) and then
    configuring sudo to allow the user myscriptrunner to run whatever
    command you need without entering the root password in /etc/sudoers is
    the way to go. Then as myscriptrunner the script would invoke sudo
    /usr/bin/whatever to run as root.
    You'll need to modify the sudo config file /etc/sudoers if you want to
    disable the need for an interactive user to type the root password
    when using sudo.

    man 5 sudoers

    Tag_Spec ::= ('NOPASSWD:'

    will be of particular interest, but you'll want to limit being able to
    run that way down to the specific command or commands your absolutely
    must be able to sudo rather than saying "yeah this user can do
    whatever as root with out a password."
    Todd H., Apr 7, 2008
  13. Yes, I need to do it remotely. What I do is I first update the zone
    files with cvs update (as regular user), and then I sighup the
    nameserver as root.

    I think that your idea is good, however:

    The problem is that, even without root logon, hacking my personal
    account means inevitable root access, because root runs my scripts. So
    the value of isolating those root commands, is very limited.

    Ignoramus10392, Apr 7, 2008
  14. Ignoramus10392

    Todd H. Guest

    If your account is only NOPASSWD enabled to run your specific scripts
    (and there's nothing keeping that HUPping of the nameserver from being
    put into a one line script owned and writeable only by root), your
    scripts are written decently, and "your" scripts are ACL'd to not be
    modifiable by your user account (e.g. owned by and writable by root,
    not writeable by group or other), you've at least contained what they
    can do as root with your compromised user account.

    Well, assuming there aren't unpatched local privelege escalation
    issues on your system, or loose file permissions elsewhere that'd lead
    to an escalation. In which case the compromise of any local user
    account is game over.

    Best Regards,
    Todd H., Apr 7, 2008
  15. Ignoramus10392

    David Brown Guest

    The other advantage of doing it this way is that any attacker using
    brute-force attacks needs to guess the name of the utility account as
    well as the password.

    Other useful tricks for ssh security are to rate-limit the port
    (especially on any internet-facing ports) - setting a limit of 3 per
    minute with a burst of 3 lets you easily log in, but will ruin brute
    force password crackers or denial of service attacks on the port. It
    can also be worth putting ssh on a non-standard port - use a high port
    number, and maybe have some automatic blacklisting for neighbouring
    ports, so that port scans will not catch the open ssh port.
    David Brown, Apr 7, 2008
  16. I am greatly interested in this ratelimit, what is the setting?

    I am getting probed, and fingered, a lot, and whatever I can do to
    limit the chances, I would do.

    Ignoramus10392, Apr 7, 2008
  17. You generally should not allow root logins, passworded or otherwise.
    Just some (non-priviliged) user(s) (you and other 'trusted' users) who
    might have suitable sudo access, as appropriate.
    Robert Heller, Apr 7, 2008
  18. Yes. su requires the root password and sudo requires the user's
    password. In either case, the ssh login is for a non-priv username, not
    root's. You generally should NOT log in as root, either locally or
    remotely. You should NEVER log in as root and do any sort of non-admin
    work, like surf the 'net, read E-Mail, play games, edit documents,
    compile programs, etc.
    Robert Heller, Apr 7, 2008
  19. A variation of this is to use the command field in the authorized_keys2
    file to bind a particular key pair to a particular command. For example,
    here's such an entry from the login used for remote backup:

    command="/opt/sudo/bin/sudo /root/" ssh-rsa AA...

    This makes scripting of remote privileged commands quite simple with the
    added benefit that revoking rights can be done quite selectively.

    - Andrew
    Andrew Gideon, Apr 8, 2008
  20. Ignoramus10392

    David Brown Guest

    If you are writing your iptables by hand (rather than using some sort of
    firewall/iptables front-end), you might have:

    iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    --limit-burst 3 -j LOG --log-prefix "SSH ACCEPT "
    iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    --limit-burst 3 -j ACCEPT
    iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    --limit-burst 10 -j LOG --log-prefix "SSH DROP "
    iptables -A INPUT -p tcp --dport 22 -m limit --limit 1/minute
    --limit-burst 1 -j LOG --log-prefix "SSH FLOODED "
    iptables -A INPUT -p tcp --dport 22 -j DROP

    This setup will log accepted and dropped ssh attempts, but if there are
    too many drops, it will give a "flooded" log message rather than filling
    your log.

    You can think of a rule with "-m limit --limit 3/minute --limit-burst 5"
    as having a bucket with space for 5 tokens. A packet will only match
    the rule if it can get a token from the bucket, and the bucket refills
    at the rate of 3 per minute (1 per 20 seconds).

    If you are getting a lot of attempts on port 22, you might want to
    consider using a different port - it's just a matter of specifying "-p
    XXX" on the ssh command line when accessing the server. It's an easy
    trick that will spoil a very large percentage of automated attacks.

    You can also add rules to drop all ssh traffic that does not come from
    specific network addresses if you know what addresses might legitimately
    need access. If users need access from home using dynamic ip addresses,
    it is still possible to restrict access to an ISP's range of dynamic
    David Brown, Apr 8, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.