root login or sudo user for server administration?

I'm trying to understand the technical arguments/security implications between ssh'ing with root directly, or making an auxiliary sudo user in the context of maintaining a server. To clarify, we're talking about servers owned by a single admin. For multiple people working on the machine, it's obvious that there is the audit trail benefit of having unique users for each actual person and fine-grained permissions.

My thought is, if this is a desktop station, it makes sense and is recommended to use a non-root user for daily stuff, but on a server, you usually login to maintain it and 99% of the times all your activities require root permissions.

So is there any security benefits in creating a "proxy" user that you're going to sudo to root anyways, instead of directly providing ssh access to root?

The only benefit I can think of is security through obscurity i.e. bots would normally try to probe for "root" user. But from how I see it, if a sudoers' user gets compromised, it's the same as compromising the root user, so game over.

In addition, most remote administration frameworks, NAS systems, hypervisors, encourage usage of a root user for web login.

One thing to consider: If using SSH keys for remote authentication, what happens if the private key is compromised?

If root: root access is compromised. Hope you weren't using that key for root access on multiple machines.

If user: That user is compromised. However, an attacker might not be able to run sudo since the user's password isn't compromised. Yet. (Assuming that a password is required to use sudo)

Still a bad situation, but a possibly better one. (Also a bit better if you use passphrases for your SSH keys)

For all uses, I strongly suggest you to not use root; even to disable it if possible. I routinely have root disabled on Linux/UNIX servers. Root user cannot be fenced, its actions are not logged. At the very least, a sudo command will be logged, very helpful in case of admin mishandling. You can also fine grain permissions to users, giving some privileges only. Of course with root disabled, no ssh logging using root is possible.

From experience, root is missed only in case you need to boot in single user or emergency boot; a rare scenario when a server cannot properly boot. But if that's the case, you can enable it, change its password and proceed to recovery.
Another case is for copying files using sftp (or ftp, which should be avoided of course, unless in internal networks only) where you need to directly copy to/from directories with root permissions only. In this scenario you can use ACLs to give permissions to another user and proceed.

on a server, you usually login to maintain it and 99% of the times all your activities require root permissions.

I would like to contest this. There are many routine tasks that simply look up information that any user can see. "top", "ps", "df", looking at logs, etc.

Get in the habit of running only the commands that needs root as root. And triple check those commands to make you haven't misspelled anything.

If you run everything as root, you WILL get sloppy. It happens to everyone.
When sloppy, you WILL make mistakes. It happens to everyone.

Don't get in that habit.

(I also agree with what several others have said about being the only admin today doesn't mean you will be the only admin tomorrow)

Security Consultant here.

Best practice across all applications, systems, solutions, operating systems and anything else you can think of is to only use the root account for setting things up then disabling it.

By all means create an individual user account with admin privileges for day to day management, but the root account, whatever it might be, should be disabled once setup is complete.

Obfuscation of accounts still isn't a bad idea, i.e. don't name your admin accounts admin but the real-world value of this is incredibly low. Most "hacks" occur over weeks and months rather than seconds and minutes like the media/movies/tv shows like to present and anyone will the skill set to "hack" you will also have the skill set to check things like the windows admin SID (it's always S-1-5-32-544 for the built-in windows admin).

For most companies a big security concern is that you need an audit trail and personal accountability.

Default (administrator) accounts like the root account are, by definition, not personal. Leaving them open leads to (the equivalent of) the bad security practice of shared passwords and no personal/individual accountability.

Normally when a colleague leaves the company you want to disable their account and know that locks out their access.

You don’t want their leaving require resetting passwords (and ~/.ssh/authorized_keys files) of every root and other shared accounts which leavers (may) have had access to. That is PITA administrative job that frequently won’t happen so you need to prevent that from becoming an issue in the first place.

So even in a one person IT department, please set up a personal account for you as the administrator, grant yourself sudo privileges or other administrator roles and do not log in directly as root or whatever default super user/administrator account is available.

So when either your company grows and you become a two person IT department or whenever you leave, you won’t leave an uncertain mess of excessive privileges that need cleaning up.

In a new job you don’t want to spent your first working days cleaning up “back door access” left by a predecessor, nor do you need, as the leaver, to run the risk of your access that wasn’t rescinded causing security breaches.

Like all security questions, it's a question of risk appetite. As others have stated, SSH'ing as a non-root user with a key and then elevating to root means there's a second factor at play (you HAVE the key, you KNOW the password), which can limit the blast radius of a compromise. There's the audit aspect too, which others have mentioned.

If you are happy with not having that extra layer of protection (however slight it may be), then do as you wish.

Most security guides recommend disabling root SSH, primarily because it forces you to allow-list a user permission to do something. There's a positive action required from you to give a user sudo privileges. You can further control what actions that user can do, so you might have seperate users for seperate tasks even. Or an automated user that can run certain sudo commands but not others.

Anyway - many security benchmarks recommend disallowing SSH, and even disallowing root from the console itself. I only do this myself if I can be sure of my backup/rebuild/immutable infra tooling, as otherwise there's no way of getting back into the server without doing some live-CD booting trickery.

This is purely a question of security vs convenience.

Logging in as root will always be more convenient but significantly less secure. So if you are OK with those caveats, you can log in as root.

However, the larger your company is, the more serious they will take security.

For example, my current employer is a company with 50'000+ employees in 5 countries. Getting ROOT login is absolutely impossible. And getting SUDO access also takes about 2 weeks, with signoff from Director levels.

If you are using ssh keys it is usually fairly safe to just ssh straight to root instead of making confusing "Proxy" users.