I am seeking observations about common practices in the enterprise with respect to server root accounts versus traditional industry recommendations. The thread is about common observed practices and not recommended practices and with respect to business networks rather than home or labs.

* Is logging into servers directly with the root account common?

* Is creating a server with only the root account common (no user accounts)?

* If creating user accounts is common, are the accounts single user accounts accessible by all users or accounts specific to each user needing access?

Both remote SSH access and local access are included in the questions.

Thanks for your time.

Background: At work I am gathering information for the owners about common industry configuration and security practices.

I'm not looking for judgments or criticism. Just what is commonly observed in the enterprise. I work for a really small less than 10 employees mom-and-pop and not in a large or mid-size business.

At work I inherited responsibility for several Linux servers. Several of these systems are public-facing. Nominal good news: all have remote SSH configured for keys only. Not good news: almost all of them only have a root account. Not good news: all servers use the same root password for local logins. Nominal good news: none of the systems have ever been knowingly compromised.

My understanding of the traditional recommendation is disable the root account but if impractical then create user accounts for each user who needs access and elevate privileges as needed from the user account. For auditing and control, creating a user account for each user needing access is preferred rather than a single account accessible to all.

As is often is the case at many businesses, at stake here is a heavy focus on convenience versus basic security practices. Part of my notes is being able to present to the owners the perceived risks vs, perceived benefits.

As observed in two business environments where I worked with Unix/Linux systems:
1. Not as far as I observed, but I never had root access in either location. I only saw that when an admin I was working with needed root, he su'd to it, did what he needed to do, and exited.

2. Definitely not common as far as I saw.

3. Single user accounts shared by all users. For example, the Informatica admins all logged in with the same account. The DBAs all logged in with the oracle account. Etc.

My best practise is:

1) Disable root login remotely, except in extremely limited and controlled circumstances.
2) Servers should be created with either local user accounts or some form of common authentication mechanism (AD/LDAP).
3) Users must only have access via their own account and sudo use permissioned accordingly.

Only from the direct, physical console, never over network. And access to the physical servers should be GREATLY restricted and monitored/logged.
That's like asking, 'How high is up?"....depends on what the server does. If all it is ever going to do is be a mail relay, it doesn't NEED any other users. Less users = less accounts to compromise/audit. That said, we will typically encourage clients to have at least ONE 'regular' user on the system, with sudo rights, in the event things go pear shaped.
Again, depends. If it's a generic user with just-in-case access, then anyone who knows the account ID and password can log in. For specific users, we always recommend tying an account to an address/range, so that only xxx users can log in from VPN, yyy users can log in locally, etc.
Was only assuming SSH access, since local access to a server shouldn't be given at all in an enterprise setting, if you're even remotely serious about security. If you're talking about local workstations, they obviously have root access AVAILABLE, but we don't suggest giving a local user access to that, but have a sudoers file that's pretty comprehensive. Lets them get work done, but won't allow system services to be modified/changed.
Best advice is, "Talk to the users and find out what they *NEED*, and be sure to separate it from what they *WANT*". And remind said users that they don't have a computer at the office....the company lets them use one of theirs during working hours. So whining about "Well, I can't install whatever I want! I can't visit porn sites! Ugggggghhhhh!!!", needs to fall on deaf ears. If user xxx needs to just run a few programs that may need root access, it's fairly simple to shove a command into a shell script that calls sudo to run it on a double-click on the console, or will fire it up from the CLI, but NOT allow them any elevated access. Get them what they NEED to work, because at the end of the day if the systems are broken, it falls to YOU, not them, to fix.

every company has its own "style" or recommendation (or policy). There is no common base, or it is just a trivial/basic set of configurations.

We have hosts where I can log in as root, but also there are others where I cannot do that. Also there are some users [locally] installed, but others coming from LDAP or somewhere else.
Accounts creation and configuration based on web services, mainly by automated scripts, but also sometimes human intervention is required.
Users are restricted so they can login only to a limited set of servers (including unix/linux/windows/whatever).


Our company has a security department and for example they are responsible for configuring firewalls, proxy, groups and similar things.... (including for example virtual hosts, docker images too).

Direct root login is still allowed by some distros (e.g. RedHat derivations) but discouraged by others (e.g. Ubuntu).

Having said that even on my RHEL systems I mostly rely on sudo even when I want to become root (e.g. "sudo su -") rather than direct login as root. However for some issues (e.g. fsck of root filesystem fails) having access to the root password is required.

Also these days many systems interact with each other so it isn't unusual to have a root ssh trust between them so that a root cron job on one system can automatically run root commands on another. If it doesn't require root access ssh trusts can be setup between non-root users.

1 members found this post helpful.

Thank you for the replies. Based on this thread, there is a difference between common observed practices and so-called recommended practices.

Working in a very small mom-and-pop is quite different from the enterprise shows. After more than two years I still haven't convinced the owner to at least encrypt the master password spreadsheet. Convenience is more important.

Similarly, one password to rule them all. I keep trying to explain that if one system is compromised all are compromised.