41

I've installed Google-Authenticator on a CentOS 6.5 machine and configured certain users to provide OTP.

While editing /etc/ssh/sshd_config I saw a directive "PermitRootLogin" which is commented out by default.

I would like to set "PermitRootLogin no" but to still be able to ssh to the machine as root only from the local network.

Is that possible?

Improve this question
11
  • 5
    Don't ever do this. SSH in as your users, then use sudo to elevate permissions. Do this so that it leaves a paper trail, and so you'll know which account was compromised.
    – SnakeDoc
    Jul 18, 2016 at 16:42
  • 8
    @SnakeDoc: That's one school of thought, but it's not clear-cut and I would argue the opposite. sudo is a huge complex attack surface and not something I would ever want to have installed. SSH pubkey auth is a much smaller attack surface. Either can be logged, but logging is not very useful when the user (root) can edit or delete logs, which is always the case unless you log to external append-only storage.
    – R.. GitHub STOP HELPING ICE
    Jul 18, 2016 at 17:21
  • 1
    @R.. If you setup sudoers correctly, using principle of least privilege, these issues you described are largely not a problem. No user should be able to ssh in and sudo - su into root, or do anything their users doesn't need (in sudoers, you use white-list for commands). If you need root, you must physically be at the console - ie. Root over SSH should never be allowed... keys or not.
    – SnakeDoc
    Jul 18, 2016 at 17:30
  • 1
    @SnakeDoc: You're mistaken. Sudo has both its own complex attack surfaces, and fundamental complex attack surface that's inherent to being a suid binary, in the form of all the state that's inherited across execve. In some cases a bug in the suid program itself (suid) is not even needed; bugs in underlying infrastructure such as the dynamic linker (e.g. CVE-2010-3856) may be sufficient.
    – R.. GitHub STOP HELPING ICE
    Jul 18, 2016 at 17:40
  • 1
    @R.. You assume you will always know if a key is leaked. That's one heck of an assumption. Further, once in, your attacker has root privileges. It is still better to send them through an unprivileged account, and make them have to elevate to root. This way you have a key that must be leaked, a key passphrase to break, and then a regular user account password to break. And if the attacker gets through all that... they can't do anything because this user is setup under sudoers with very limited capability... See the benefit now? Don't allow direct root login over ssh... period. It's good hygiene
    – SnakeDoc
    Jul 18, 2016 at 20:55

3 Answers 3

Reset to default
62

Use the Match config parameter in /etc/ssh/sshd_config: 

# general config
PermitRootLogin no 

# the following overrides the general config when conditions are met. 
Match Address  192.168.0.*
    PermitRootLogin yes

See man sshd_config

Improve this answer
4
  • 8
    You can also restrict the source for authentication keys in ~root/.ssh/authorized_keys. Prefix the key with from="192.168.0.0/24 ".
    – BillThor
    Jul 17, 2016 at 13:20
  • 10
    I would change it to also permit IPv6 link-local addresses. The way link-local addresses work in IPv6 make them very robust to misconfigured networking. Which means if you need to ssh in to fix a network misconfiguration, it is possible that using an IPv6 link-local address is the only option left.
    – kasperd
    Jul 17, 2016 at 16:24
  • FYI If you additionally use the directive AllowUser, you have to additionally (and counter-intuitively) also do AllowUser root
    – Robert Riedl
    Jun 14, 2019 at 9:32
  • What if IPv6 is used?
    – Alexey
    Dec 21, 2019 at 19:10
15

The Match address method was already mentioned, but you can also restrict the users (or groups) that are allowed to login onto a system. For instance, to limit logins to the user itai (from anywhere) and root (from a specific network), use:

AllowUsers itai root@192.168.0.*

This prevents all other users (like apache) from logging in through SSH.

See also the AllowUsers keyword in the sshd_config(5) manual.

Improve this answer
3
  • 4
    I prefer AllowGroups and adding all users that should be able to log in using SSH to a specific group. Guess it's a matter of taste, but that seems like less editing of sshd_config (which translates to less risk of messing up and locking everyone out).
    – user
    Jul 18, 2016 at 8:44
  • 1
    @MichaelKjörling Also, AllowGroups means that you don't need edit permissions for sshd_config if your team expands or shrinks. This might even allow more managerial types or interns to do it.
    – Nzall
    Jul 19, 2016 at 12:09
  • Good points, note that you can combine options, have AllowUsers itai root@192.168.0.* and AllowGroups ssh-users and you will not accidentally cause a lockout in case the intern accidentally clears the group :)
    – Lekensteyn
    Jul 19, 2016 at 16:38
1

A different strategy could be to leave PermitRootLogin set to no for all addresses, but allow a different user to log in and use sudo. One benefit of doing this is that you can limit what that user with sudo configuration. This is an added layer of protection, in addition to limiting what IP addresses the admin user can log in from.

In /etc/ssh/sshd_config, disable root logins:

PermitRootLogin no

Create a different user called, say, admin. Configure the allowed IP addresses in this user's authorized keys file, /home/admin/.ssh/authorized_keys:

from="192.168.0.0/24,fe80::%eth0/64" <your public key here>

In this example, I also allowed traffic from IPv6 link-local addresses. This is helpful if you use mDNS that may resolve to an IPv6 address or if you need to access the server even when routing is broken. Note that the eth0 part of the address will change based on the interface name on your server. Use ifconfig or ip link to list valid network devices for your server.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.