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?

  • 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 '16 at 16:42
  • 7
    @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 '16 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 '16 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 '16 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 '16 at 20:55

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

  • 8
    You can also restrict the source for authentication keys in ~root/.ssh/authorized_keys. Prefix the key with from=" ". – BillThor Jul 17 '16 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 '16 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 '19 at 9:32
  • What if IPv6 is used? – Alexey Dec 21 '19 at 19:10

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.

  • 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 '16 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 '16 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 '16 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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