Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have read the answers regarding why you should disable remote root login, but there is something nagging me. Assume this:

  • Scenario 1:
    • Remote server A.
    • Remote root login disabled.
    • Password authentication is disabled.
    • User A is using rsa authentication to log in.
    • User A runs /bin/su - to become root and enters the root password.
  • Scenario 2:
    • Remote server B.
    • Remote root login enabled.
    • Password authentication is disabled.
    • User B is using rsa authentication to log in as root.

I already know the saying about multiple lines of defense, and yes - I know that bots on the internet are more likely to try breaking in using root compared to most other logins, but does scenario 1 offer any significant advantages over scenario 2 if you assume that an attacker finds a way around the rsa authentication (either by hijacking, exploits or just copying the key file) used in both scenarios?

Lets say that an attacker gets access to server A, and is able to log on as user A. Isn't it right that from that point on, user A can't log in and su to root without potentially sharing the root password with the attacker? Is it difficult to just add a home made command at the end of the users login shell script that will intercept and relay (or store) the root password?

My point isn't that it is safe to let users log in as root remotely, but that forcing the users to log in using another account is almost as unsafe - modulo various bots that are always hammering away on root accounts everywhere.

Am I missing something?

share|improve this question
2  
It isn't the login process that is unsafe, it is the fact that nobody should be doing ALL of their work on a server as root. –  Rell3oT Apr 26 '13 at 22:31
    
Also, it prevents ANY attacker who happens to guess a password or find a key laying around from becoming root on your server. –  Rell3oT Apr 26 '13 at 22:44
    
Don't use su, use sudo - no need for a root password. –  Martin Schröder May 2 '13 at 8:56

1 Answer 1

Just off the top of my head:

  • If user's credentials are compromised, locking out that account in the user directory is much quicker and reliable than editing /root/.ssh/authorized_keys on all systems to remove that user's key.
  • Linux auditing daemons distinguish between "uid" and "effective uid". Users who ssh in as themselves and then sudo to gain privileges will be seen by the audit daemon as "user bob acting as root" vs just "user root" if they ssh in directly as root. Having an audit trail that goes back to the user performing the actions is important.
  • You can require a 2-factor authentication token for sudo. While this can also be done on the sshd level, this requires a 3rd-party patch and significantly impacts usability, as this can't be just enabled for a group of users.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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