up vote 2 down vote favorite
share [g+] share [fb]

I want to prevent the root user from logging in directly from local console on a RHEL box, but allow login from ssh. Can this be done?

Thanks...

link|improve this question
2  
Typically you'd want root to be allowed at the console while removing it from remote access for security, and allow particular functions through Sudo...is there a particular reason you want this setup? – Bart Silverstrim Feb 9 '10 at 16:29
1  
I want to lock a server from tampering with locally while allowing remote management through ssh. Thanks. – Moutaz Feb 9 '10 at 16:31
2  
If someone you don't trust has physical access to the machine you're already screwed, it's just degrees at that point. Locking out root as I describe below just means they have to reboot the machine in order to get in... – voretaq7♦ Feb 9 '10 at 16:39
@Bart - I lock my machines down in a similar way to what I describe below (except I do all my remote work via sudo instead of allowing root to SSH in) because the datacenter I host in doesn't guarantee physical security. A measure of paranoia that I admit is largely unnecessary, but it makes me feel better :) – voretaq7♦ Feb 9 '10 at 16:42
@voretaq7: I didn't mean to say it was wrong, just that normally it's done the way I described in the comment, and in some cases it's worth evaluating why you want to use another approach to see if it's the right one for that case (sometimes there's a better solution for the problem rather than asking about a process). Hope that makes sense... – Bart Silverstrim Feb 9 '10 at 17:05
show 1 more comment
feedback

2 Answers

up vote 4 down vote

Yes.

  1. Create a SSH key for root & add the public half to ~/root/.ssh/authorized_keys.
  2. Edit /etc/ssh/sshd.conf - Set PermitRootLogin to without-password
  3. Restart sshd
  4. TEST IT -- Make sure you can log in as root over SSH using the key.
    • TEST SINGLE USER MODE - Make sure it doesn't ask for root's password (Once you complete step 5 root will no longer be able to log in using a password, so and breaking single-user mode can be a Bad Thing)
  5. Lock out root's login password (replace the password field in /etc/shadow with *, x, etc.)

Notes:

  1. Your machine can still be rooted by anyone who can walk up to the console (because single-user mode won't ask for a password), but your machine will go down when they try it so you'll theoretically know.
    • If you configure single-user mode to require a password the only way to perform recovery work on your system is to use a recovery CD, and you're in the same security boat as above, but now the hacker is annoyed.
  2. Your machine's network profile is now only as secure as root's SSH key, so make sure to set a good passphrase & keep the key in a secure place.
  3. If you lose the SSH key the only way to get back in to the system as root is to reboot in single-user mode (or hack your own box).

An alternate configuration is also possible where a separate sshd that listens for root logins is only avaliable on localhost & you use agent forwarding to log in as root. I know at least one major corporation that has that configuration, and it adds one more layer of security (and complexity).

link|improve this answer
1  
do this and encrypt all volumes on the disk and you'll really annoy whoever is trying to get in as it won't come up correctly without you entering a password on boot. So long as someone else has physical access to the machine you can never guarantee security however every little bit helps. If you are going to try this have good backups however as recovery will be difficult/impossible if something goes wrong. – Antitribu Feb 9 '10 at 17:17
1  
I did the fully-encrypted-needs-a-password-to-boot thing once - visiting the datacenter after every kernel patch really sucked :) You can encrypt a volume (that doesn't mount at boot-time) to store your sensitive data on though - definitely a good idea. – voretaq7♦ Feb 9 '10 at 17:39
1  
I suppose it entirely depends on your level of paranoia. If you don't encrypt the boot partition you can't be reasonably sure that the system hasn't been tampered with on a reboot (eg rebooted with a root-kit) I suppose you could install tripwire and keep the hashes on a second encrypted partition and only mount the data when your sure the system integrity has been maintained. At some point you just have to take off the tin foil hat though. – Antitribu Feb 10 '10 at 10:05
1  
@Antitribu: But the tinfoil hats are DEAD SEXAY! :-) (My tinfoil only extends to locking out root on the console while the system is multi-user - I figure if the attacker is ballsy enough to reboot the box they're also probably ballsy enough to just steal a drive out of the RAID mirror :-) – voretaq7♦ Feb 10 '10 at 15:18
feedback
up vote 2 down vote

Disabling local root login is bad idea. The access may be necessary in system crash situations. According to NSA RHEL 5 security guide, 2.3.1.1 Restrict Root Logins to System Console:

Direct root logins should be allowed only for emergency use. Innormal situations, the administrator should access the system via a unique unprivileged account, and use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root canconnect directly reduce sopport unities for password-guessing against the root account.

(...)

Root should also be prohibited from connecting via network protocols.

Disabling root login from local console can be done by removing lines tty1 tty2 tty3 tty4 tty5 tty6 tty7 tty8 tty9 tty10 tty11 from /etc/securetty.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard