Source Guru

Why shouldn’t I login as root?

by on May.27, 2010, under Personal

I’ve recently gotten a lot of flack from a couple of people for an innocent comment I made about logging into a machine as root.
I’d like to think of myself as pretty savvy when it comes to security, and as far as I’m concerned, the reasons for not logging in as root are:-

  • Password could theoretically be sniffed
  • Unsecure connection could theoretically be hijacked
  • You don’t get an audit trail like you would with su or sudo
  • Password could be brute forced
  • You could easily run a command unintentionally which causes damage to your system

Ok, so we have the reasons not to – and they’re good reasons. This is why, generally, I don’t login to my boxes as root. However, the box in concern mitigates the above in the following ways

  • We only ever connect via SSH
  • Access to root is only allowable through SSH keys
  • Due to the nature of the server (local file storage) we don’t need an audit trail
  • Password login is only ever allowed from a secure TTY (aka the box itself)
  • The only reason we ever need to login to this machine is to perform maintenance which requires root access

Is there any good reason that I shouldn’t be logging in as root in the above circumstances?

:,

33 Comments for this entry

  • Tomalak Geret'kal

    No.

  • Dmitrijs Ledkovs

    set up sudoers correctly to allow users you want to run commands you want =) it’s a simple human protection from a silly recursive remove command which will ask you for a sudo’s password ;-)

  • alex

    You need a shared password. With sudo you can use your existing password, so no need to learn a new password. Also, if someone needs their access revoked to the box, you only need to disable their account.

  • Ray

    If you get comprimised as a user, the hackers get the user, but that’s about it. If you get comprimised as root, the hackers get the system. Not logging in as root is a safety precaution for the off chance that there is a vulnerability in your software stack, and you do get hacked… I mean, they can do some pretty damaging stuff with even just a short time as root, like undo all those precautions you mentioned…

  • Ron

    “Is there any good reason that I shouldn’t be logging in as root in the above circumstances?”

    Yes.

    Even thought you are going over SSH, and even though it PROBABLY can’t be sniffed, that doesn’t mean it CAN’T be. Now, we can go ’round and ’round about this and that, but the real question is: Why do you need to login as root?

    Will sudo not work?

    Is there something you need that that cannot be done via sudo that REQUIRES you to login as the root user?

    You want to use the least privileges possible. In other words, use whatever credentials are necessary, no more, mo less. If sudo works, don’t login as root. If you can do something as a normal user and don’t need sudo, then don’t use sudo. This is really a security mindset.

    Ron

  • anonymous

    > Is there any good reason that I shouldn’t be
    > logging in as root in the above circumstances?

    Yes, to shut the annoying people up.

  • Timo Juhani Lindfors

    People also often forget that if their normal user account ever gets compromised it is easy to wait in the background for the next sudo invocation and get root. Normal accounts get compromised more easily than the root account since people run web browsers and pdf readers. Also unless you have configured logging over network the audit trail of sudo can easily be removed when the attacker has gained root privileges (maybe one day we’ll have some selinux style setups where not even root can erase log files).

  • Mez

    @Dmitrijs Ledkovs – but everything we need to access the server for requires root, so all we’re going to do is sudo -i.

    @alex – no passwords are able to be used (except for physical console) – which is limited. Revoke access? Remove the SSH key

    @Ray – We have safeguards against our local software stacks being poisoned.

    @Ron – someone would need a LOT of computing power to sniff an SSH stream as it stands at the moment. We’d notice a mainframe in the car park. The rest of your argument just seems like “Well, if you can do it that way – do it that way” – in theory – your argument would mean no remote access whatsoever. We can always go to the physical console.

    @Timo – indeed, espesically, as with sudo’s implementation of not requiring a password every time, a normal account with sudo access (in my eyes) is potentially more dangerous (though theoretically unlikely). At least with an SSH key, a password is needed

  • Ron

    @NMez

    “someone would need a LOT of computing power to sniff an SSH stream as it stands at the moment. We’d notice a mainframe in the car park. ”

    True. It is POSSIBLE, but not PROBABLE, therein lies the difference. The fact it is POSSIBLE, leaves room for doubt on security. I err on the side of caution and paranoia.

    “The rest of your argument just seems like “Well, if you can do it that way – do it that way” – in theory – your argument would mean no remote access whatsoever. We can always go to the physical console.”

    Yes, this is deal. If you have local, physical access to the box on a regular basis, then remote access (even encrypted) still poses a risk.

    All that being said though, you never answered my questions.

  • ethana2

    Your bash aliases won’t work and you have to practically learn another language just to administrate the machine.

  • Leandro Penz

    On the other hand, there is no good reason to login as root.

  • TIm

    it’s flak not flack

  • Eric Hammond

    I don’t particularly care if you ssh as root or not, though I’ve chosen to not. I wrote the following article for people who are used to ssh as root and are forced to do otherwise (originally targeted for users of Amazon EC2):

    http://alestic.com/2009/04/ubuntu-ec2-sudo-ssh-rsync

    – Eric Hammond

  • Anonymous

    The biggest argument: each administrator can have their own personal configuration in their home directory (editor, shell, aliases, scripts, and other miscellaneous dotfiles), whereas root only has one configuration.

  • Andy Cater

    If all you ever want to do is run a couple of commands – e.g. to a headless box which has no keyboard: ssh keys with forced commands may also help.

  • Mez

    @Tim It can be either.

  • Mez

    @Leandro Why not?

  • Mez

    @ethana2

    1) I use zsh
    2) We generally all use the same subset of commands. Not many of us use aliases. I prefer to use the command I want to use instead of having issues logging into some random box and finding the command doesn’t exist, then spending time finding out what the actual command was

  • Mez

    @Ron

    Then, to answer your questions

    1) No
    2) Not having extra attack vectors from usernames that don’t get used

  • Mez

    @Eric

    Great link!

    Personally, my own boxes, I’ll never login as root… but that doesn’t apply @ work.

  • Mez

    @Anonymous Good point – but generally the only thing we edit on these servers is the .vimrc – and we all share a common one.

  • Mez

    @Andy If only that were the case :(

  • Gert

    Security is all about closing up possible attack vectors. Do you Really NEED that ssh root login? Is it possible, maybe with a bit more effort, to do whatever you need to do on there without loging in as root? If so, then why not close up that one attack vector? (Devils Advocate answer: its convenient – but security is not about convenience :/)

    And yes, you make the point that the root ssh access is set up with SSH keys, which are generally considered safe.
    Except that one time last year (or so) when people discovered a bug in the relevant code, making all SSH keys vulnerable. Possibly including the one you depend on for your root access (Its possible you weren’t actually affected, this time, but..) It was fixed within days if I remember correctly, but in the mean while, your root SSH would ‘ve been wide open.

    Now if you simply disallow ssh login as root (“PermitRootLogin no” in the sshd_conf), thats one less vector to be concerned about. :)

  • JW

    After a protracted conversation about this with someone on IRC, I think I refined my recommendation on this. There are several good reasons stated here why it is a potential security issue. However, at the end of the day it is your decision with your computer. That being said, I urge you not to promote this as a best practice. In general, it is a safer and better practice to log in as a user who has been granted permissions via the sudoers list. Along those lines, if hope if you are maintaining computers that are not your personal computers you are doing the ultimate system owners a favor and not logging in as root; you could be compromising their system security based on your preference here. Root is a powerful user to have compromised.

  • Mez

    JW, I completely agree, and I’d never promote it as best practice… it’s just practice here.

  • Ron

    @Gert – Agreed. Security is not about conveience.

    @Mez – Then if:

    Ron: Will sudo not work?
    Mez: No

    Ron: Ron: Then nowThen now I must ask: Why not?

    Ron: Is there something you need that that cannot be done via sudo that REQUIRES you to login as the root user?

    Mez: Not having extra attack vectors from usernames that don’t get used.

    Ron: Then logging at as root is MORE of a risk. Think about it. root is open wide. root is KNOWN to exist on systems. It, like “Administrator” on Windows, is the default account to be attacked. (which is why I always rename it to something else instead.) On Ubuntu, root is disabled by default and the first account created is in the sudoers file. You can easily limit that account, thus making it much more secure than logging in as root.

    Q: Why do you need to login as root?
    A: You don’t need to. You WANT to. It’s just like the people that think they NEED wifi in their house when they can just run CAT5e cabling instead, which is faster and more secure. Laziness, Ego. Not sure what the reasons are why people do that, but *NEEDED* isn’t one of them.

    Ron

  • Carsten

    Well, if a direct ssh connection for user root could be sniffed, te same applies to getting the password for the sudo via ssh connection.

    If you need root access for several users, but want some kind of audit trail:

    Create multiple root users (all have the same uid/gid 0/0), but they have different home directories thus their own history, settings, shells…

    If you don’t trust the local system, forward your log files to a dedicated “locked down” syslog host where not a single user has ever access to (require two distinct local passwords via pam).

    The biggest issue still is that you cannot check if the people use a good passphrase (or one at all) for their ssh private key, thus you might need a good way to revoke such keys: For that I’d put the ssh keys on a physically made read-only memory – provided no one can access the system easily and mount the ssh public keys from there (and enure that ssh reads them from there only.

    Final comment, go for ssh with x509 certificates (patches see globus.org or VDT). There user names are in the certificate in clear text and people are usually more conscious to protect things where their name is directly attached to (call it “social security”) ;)

    HTH

    Carsten

    PS: I’m working on *many* machines and unfortunately it’s 90% the time as root – it works, but you just need to get into the habit of thinking before you type, rarely use rm, use mv first and rm later, and so on

  • Dirk

    Not to login as root is one of the so called “Best Practice”. And like many “Best Practices” they were introduced many years ago. After that they were pushed by many people. But not anyone ever thinks about if they are still right as they might have been ages ago. Times change, systems change, people change and findings and insights change.
    A lot of “Best Practices” are meaningless and often counterproductive today. Just think of the rules to change passwords on a regular basis.

    Same is right for “Never login as root”. It was instituted in a time where you logged in via telnet, rsh, ftp, http and nearly all users had a shell-login. All connections were without encryption and only based on password-authentication.

    Today things are different. You only allow secured channels to login to a server. The first thing you do is disable Password-Auth via ssh on a new server. So there is no way anyone can ever brute force the root pw.

    Every hurdle you put up, that makes your work harder has to pass the test if it really has an effect in security that’s value is higher than the extra hassle.

    Security is about convenience in that way that if it impacts your work too much, people will find ways around the whole system to get their work done and you will end up with no security at all.

    If you allow root-logins your weak-point is the .authorized_keys if you don’t your weakpoint ist sudoers. No gain.

    Today allowing root login via ssh with keyauth only is perfectly reasonable.

  • mathew

    If you’re the only one who ever uses root (i.e. no password sharing), and you only log in via secure ttys, then there’s probably no danger in logging in as root. But what’s the point? I find it easier to follow the same procedure for root access on all machines, than to have to remember which ones are set up for root login and which aren’t.

    Hence I never log in directly as root on any machine, at work or at home. I’ve yet to encounter any situation that requires it. So I agree with Ron, get over your bad habit.

  • uray

    I run and logged in as root all the time, I even autologin it using root.

    some people value more to their workflow efficiency while other on the security.

    if you don’t care about security the risk is yours, linux is about freedom, including freedom to destroy your own data, privacy and security.

  • mchaos

    Root is god. I like to feel like god!!!!

  • Homer Smith

    A while back I ran into an sshd on a remote
    machine that was infected. When it sshd into
    my local shell machine it replaced the existing
    sshd with an infected one. Fortunately tripwire
    caught it within a minute.

    Allowing root sshd to sshd connections is only
    as safe as you can trust your sshd’s, and if
    it is someone else’s sshd, trust is poor.

    pam.d allows one to specify who can log in as root
    and who can’t. One can thus allow root access
    amongst local machines that are more trusted,
    but not from the world at large.

    Security is complicated as it tries to deny access,
    but access is necessary to get work done. For example
    when copying large numbers of root files from
    machine to machine, rsync etc, doing it without root
    access becomes more complicated and painful.

    Homer

  • L

    A good setup would be to disable root login (in tty and gui) and create a new account with a name more concealed to use as a sudo or with PID 0, but without rights to login in gui (so it cannot use pdf readers or browsers).

    Is a good idea?

Leave a Reply

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!