root vs sudo/su....

[Slavik]

So have had quite a lively debate on Skype with a group of associates with regards to managing linux servers.

The basic argument came down to, what do you use and why?

A lot of the arguments to and fourth got me thinking, and challenged pre-formed ideas I had on security.

So, i'll throw the question out to you guys also.

Do you use a su account, or just use the root login and why?

 

[AdamD]

Personally I just use root, but I have it set to you can only login with a private key, rather than password.
I also change the default SSH port to something random, with a software firewall which blocks failed login attempts after 3 tries.
If I had a static IP, I would also limit root logins to my IP, but sadly, I'm on dynamic heh

 

[Adam Howard]

So have had quite a lively debate on Skype with a group of associates with regards to managing linux servers.

The basic argument came down to, what do you use and why?

A lot of the arguments to and fourth got me thinking, and challenged pre-formed ideas I had on security.

So, i'll throw the question out to you guys also.

Do you use a su account, or just use the root login and why?

I personally use root when logging into a remote server. The argument of using sudo being more secure is kind of misleading. If someone can get access to sudo they've basically got root anyways.

The only "technical argument" only applies to a shared environment; as you can "technically" change the degree of sudo level access. But this can be over come (easily) and has lead to even the most secure systems being compromised. However, "technically" it's there.

For myself... I use root. I don't share access on that level and as I said, if you can get sudo you can go further (easily).

 

[MattW]

I personally also use root for managing my servers. You can't log into them with the root account, and that is also locked down with private keys and none standard SSH port

EDIT: also locked down to two static IP addresses.

At work, we have to use sudo as part of PCI compliance on our linux machines, but that is purely for logging purposes, as the sudo permissions are basically that of full root anyway!

 

[Jeremy P]

The security in sudo is more about preventing yourself from doing something stupid by accident. If someone has the password to an account with sudo access, it's not going to protect the system from anything.. they might as well have access to the root account.

I use sudo for everything. I almost never use the root account (even via sudo su) unless I'm doing a lot of things that require root access.

I do disable root login and force public key authentication over SSH.. but that's not much more secure against attackers than just using root with public key auth really.

 

[Luke F]

For ssh/admin tasks I don't see anything wrong with logging in as root most of the time (and that's exactly what I do) - the only real concerns are slight added difficulty in lazily running things as non-root and of course the risk of deleting/damaging important files.

 

[MattW]

For ssh/admin tasks I don't see anything wrong with logging in as root most of the time (and that's exactly what I do) - the only real concerns are slight added difficulty in lazily running things as non-root and of course the risk of deleting/damaging important files.

This is why I think it's always important to develop a good work flow when doing file edits etc. If I'm editing a file, I always create a backup of the file first. Makes rolling back much easier than trying to figure where you've gone wrong.

 

[MagnusB]

The big point of sudo is that you have to confirm your action, while su just run it. In terms of security, I doubt there is any difference. Funny thing is that in su systems, I usually run su -c...

 

[dieketzer]

i ssh in as root. i have the same safeguards most have mentioned.

 

[Fred Sherman]

The first thing I do when I take over management of servers, regardless of the type of Unix, is remove direct root login. I want accountability and I can't do that with an IP, thanks to DHCP. So everyone logs on with an individual account and must su to root.

Secondly, only unix admins have access to root. They are the only ones properly trained to handle that responsibility and even then, only after I have trained them.

All others get command level sudo access, no sudo to a shell. That would defeat the purpose.

On SOX, ITAR, or HIPAA rated servers, all keystrokes are logged.

On classified DoD servers, we run trusted versions of the OS, with a two person commit: in other words, to enter destructive command requires two passwords: the root password and then the security officer password. No one person has both. Instead of sudo, we use Centrify for more granular control, including time of day, day of week access to servers and/or commands.

 

[SneakyDave]

I only allow ssh from my certain networks, and disable root access in ssh. I have one user with a private key, and run ssh on a non-standard port. I'm still using fail2ban too, but maybe there's somebody better than that now.

I have most of my frequently used commands setup as aliases in bash, such as "nginx restart"

In /etc/ssh/sshd_config

PermitRootLogin no
AllowUsers Herbie
Port 21576
PasswordAuthentication no #only if private key is working

In ~/.bashrc

alias nginx="sudo /etc/init.d/nginx"

 

[Mouth]

No root logon
Firewall for ip blocking on brute force attempts to ssh
"sudo -i" for any root level actions.

 

[Deleted member 2163]

I'm still using fail2ban too, but maybe there's somebody better than that now.

I use sshguard (www.sshguard.net) and it's great. If you're using iptables on a Virtuozzo-based VPS (like mediatemple servers), then you will want to look at increasing your numiptent value, like so:

vzctl set 101 --save --numiptent xxxx

Side note: you'll have to restart the container for that to take effect.

 

[Jason]

I use sudo, mostly because it makes managing access easier and there's some accountability.

Direct root logon is disabled, and I rarely use the account itself -- using 'sudo -i' instead. Others are granted command level access, with no sudo to a shell. By assigning users to functional groups, I can easily manage rights with these groups in sudoers vs. managing users individually. It also allows me to manage configuration for several machines with one file (I use puppet to set classes that concatenate sudoers contents (with some validate functions for validation before deploying) -- though recent versions of sudo support inclusions).