20

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.

Improve this question
12
  • 3
    @IanW: Not knowing username is "security by obscurity", which is not security at all. Also, by introducing sudo, you are introducing potential security bugs, which can result in local privilege escalation (such as CVE-2021-3156).
    – Jakub Lucký
    Commented Feb 21, 2022 at 7:46
  • 2
    There is a third option not mentioned in the question: Using su instead of sudo, through a proxy account.
    – marcelm
    Commented Feb 21, 2022 at 10:10
  • 12
    @JakubLucký security by obscurity alone is not security at all. When used as an independent layer on top of other good security practices, obscurity is considered a valid security tool.
    – Didier L
    Commented Feb 21, 2022 at 15:11
  • 3
    @JakubLucký by introducing sudo, you are introducing potential security bugs, which can result in local privilege escalation Huh? You might as well say, "A fence might get holes in it, so we're just going to let the cows run free." Giving out direct root access because sudo might be compromised is hardly an improvement in security. Nevermind you totally remove accountability and nonrepudiation. I'm sure that'll go over well with your security auditors.
    – Andrew Henle
    Commented Feb 22, 2022 at 20:39
  • 2
    @JakubLucký I definitely wouldn't agree security by obscurity is not security at all - as all security measures, it works as a part/layer of your whole strategy, the same way like changing the default SSH port is not security per se, but eliminates virtually all port scanners and bots probing your system. Though, as I reiterated, my question is strictly focused on the technical aspect, not social engineering, not corporate policies, not religious-like beliefs and spells a'la "never use goto" :)
    – alex.b.bg
    Commented Feb 23, 2022 at 1:30

9 Answers 9

Reset to default
12

The other users already mentioned very good points. I want to recap the ones I think are most important...

...why to use sudo

  • If your ssh key for root-login is compromised, you have little chance to escape the situation properly.
  • Commands using sudo are logged, this doesn't only apply safety when there are multiple admins, but also if some attacker got into your system.
  • You have very granular options to adjust per-user permissions, is it through /etc/ssh/sshd_config or through the SUDOers file. (don't use another editor than visudo!)
  • Even if your default ssh login is compromised: An extra layer like sudo does make root permissions less accessible. (I always use Defaults targetpw - as well on my desktop machine as on my servers. So one has to know two different passwords in order to become root)

To add to the last point: I personally use seperate users for every task on my servers (I am the only admin): e.g. one user for backups. It has access to the files-to-backup and seperate ssh access to an off-site server. I have one user for monitoring, which has very limited access to logfiles and to the monitoring API. Only to mention a few examples...

But for me, personally, the most important point is that we all are humans. You will make mistakes. Having to type sudo before every command, that could change you system's behavior, at least adds one barrier which animates you to overthink your command.

So i strongly recommend: use sudo instead of the root user

From the technical point of view: There are two common ways to use the root user. Either login directly via ssh as root, or login via ssh and type sudo su or su - (...) as first command. Both of these ways wouldn't make me feel comfortable.

ssh root login

  • Independent from opening root login or not: Using ssh keyfiles is the only safe way. Don't use passwords without keyfiles. (Here is a guide)
  • Add firewall rules and sshd-rules like LoginGraceTime and MaxAuthTries to limit BruteForce attacks.
  • Leaving the option to login as root adds a security flaw. Even if it's very unlikely to utilize the flaw. (I prefer PermitRootLogin)
  • Technically, if you safeguard root login following the best practices, this is not less safe than everyday ssh.

su

  • In my opinion, the only problem about logging in as root is that you don't have to type sudo before every command, which makes you more error-prone
Improve this answer
8
  • Not to forget that you can add multiple "features" to sudo, using visudo: How long will the timestamp last? Which password will you have to type? Which commands are accessible without password?...
    – void
    Commented Feb 21, 2022 at 13:21
  • I think what you mentioned changing the sudoers config with Defaults targetpw is the only real case where you gain more security technically. In professional environment that's exactly what I'm doing, especially on public-facing endpoints - this way even if you have a sloppy password on your ssh key(and people usually reuse their "standard" passwords), even if you compromise the key, at least there is one more password that needs to be broken. But without rootpw/targetpw, at lest for now I'm not convinced a proxy user provides any technical benefits.
    – alex.b.bg
    Commented Feb 23, 2022 at 2:15
  • 1
    Coming to your point on key passwords: Actually I never use key passwords (since I only store my keys on private and encrypted devices) but I set AuthenticationMethods publickey,password in sshd_config to require a second factor this way. And afterwards I use sudo like discussing above... But surely you should password protect your keys in professional environment.
    – void
    Commented Feb 23, 2022 at 7:08
  • 1
    @lanW good point. The versed user should be able to research basic things on their own - but I'll add links for unexperienced admins. +1
    – void
    Commented Feb 23, 2022 at 12:26
  • 1
    @alex.b.bg You are absolutely right. I don't recommend not to password-protect keyfiles. It's just convenience for me. Thus, I use seperate keyfiles for every device and every ssh account plus the second factor of the target-password (server-side pam) which still remains pretty safe
    – void
    Commented Feb 23, 2022 at 14:49
16

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)

Improve this answer
8
  • 2
    Well, that private key should still have a password.
    – Dubu
    Commented Feb 21, 2022 at 14:22
  • @Dubu: a private key is just a bignumber, there's no password there. I presume you meant a password on the keyfile storing the key persistently.... but the key will still be transiently unprotected in memory, during which time it is vulnerable to exposure by Heartbleed-like bugs.
    – Ben Voigt
    Commented Feb 21, 2022 at 17:33
  • @BenVoigt The private key is just a big number. But you are asked if you want to protect that big number with a passphrase when you generate the keyfile. Answer should always be yes.
    – doneal24
    Commented Feb 22, 2022 at 16:19
  • @doneal24: That's what I was pointing out, that the passphrase protects the key only from disclosure via keyfile, not everywhere.
    – Ben Voigt
    Commented Feb 22, 2022 at 19:14
  • 2
    @alex.b.bg you mean as a non-root user with a compromised key? A user needs to input their current password to change a user password. To otherwise force a change requires admin access such as su or sudo...which, again, require passwords.
    – TylerW
    Commented Feb 23, 2022 at 2:57
9

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.

Improve this answer
5
  • 3
    I'm asking for a scenario where I'm the sole administrator of a given machine - whether I'm missing a technical/security benefit of the two approaches(e.g. a case where even the "proxy" user is compromised, it cannot do so much damage compared to the root user being compromised directly. For multiple admins/users, the audit trail argument is a good one. I'll actually edit the question to add that to the context of the question.
    – alex.b.bg
    Commented Feb 20, 2022 at 18:57
  • 1
    As a system administrator, it's important to use "Best Practice," which is to log in as you, then, when needed switch to root. TBH, if your are the ONLY user, there is no external connectivity, and you have Anti-Virus/Anti-Malware to scan installation media - your right, it doesn't really matter (please re-read those 3 caveats and make sure you completely understand them). However, getting in to the habit of logging in as root is tough to break; when you get onto a "usual and customary" system, you'll have a hard time adapting. Learn to do it right before you start breaking the rules! $0.02
    – Scottie H
    Commented Feb 21, 2022 at 16:37
  • Usually one can just sudo -s and has a root shell. In theory you could of course configure that the upgrade user can just run apt upgrade or something like this, but this will complicate things and is beyond the question of the OP.
    – allo
    Commented Feb 21, 2022 at 20:38
  • @ScottieH if your admin station is compromised(what you mentioned about antivirus/antimalware) and, say, an attacker keylogs your login procedure into a server, I think it's game over no matter how well that server is secured. But I get your point and it's really important - that security involves all nodes that are somehow connected.
    – alex.b.bg
    Commented Feb 23, 2022 at 1:39
  • If you can ask for emergency boot on the console, the root password is a speed bump, not a barrier.
    – joshudson
    Commented Feb 23, 2022 at 1:44
6

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)

Improve this answer
5

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).

Improve this answer
3
  • 1
    That's exactly my observation also - most attacks I've seen, especially on corporate infra revolve around malware on workstations because of sloppy security OR rogue action by employees later sharing the cut with the attackers. But once you own the workstation, the machines you log in from it are basically toast no matter what intermediate steps you take. So from the comments 'til now it seems using a non-trivial login name would definitely help with automated attacks and script kiddies, but not for deterring a serious actor.
    – alex.b.bg
    Commented Feb 23, 2022 at 2:01
  • 1
    That said it's almost always someone clicking on something they shouldn't. Especially an issue on older firms, I've spent years fighting the fact the same old single points of failure on key systems fail every single phishing test we throw at them go un-reprimanded. Could argue that's an insider threat if not malicious at least. imo all anyone should really be spending money on is low hanging fruit because we've all got a ton of it, i.e. MFA/2FA on every single admin account you care about will resolve a dramatic amount of any future serious incidents you might have.
    – mak47
    Commented Feb 23, 2022 at 8:25
  • Totally agree - human factor is always an easier, cheaper and more reliable attacking surface than any high tech 1337 geekiness. Why'd you invest hours upon hours probing infra when you can just email that cute_animated_cat.exe :) We're going a bit offtopic here, but in my experience, the best way to fight this is limit the damage as much as possible - jailed regular users, inability do download, limiting using flash drives, good antivirus and the word that sadly not many people take seriously - BACKUP strategy!
    – alex.b.bg
    Commented Feb 23, 2022 at 14:08
4

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.

Improve this answer
1
  • 1
    Not quite as eloquent as I would like to express myself but in a business setting don’t use shortcuts. At home ; do as you please.
    – Bob
    Commented Feb 20, 2022 at 22:29
2

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.

Improve this answer
3
  • Would it be fair to say that the 2nd layer of security would be the same as password-protecting your ssh key?
    – alex.b.bg
    Commented Feb 23, 2022 at 1:48
  • 1
    I suppose, but it's a second layer in a different part of the system. Having a password on your SSH key helps reduce the likelihood of someone using it, but once they've cracked it then there's no further mitigations to getting in as root. It's all about defense in depth...
    – shearn89
    Commented Feb 23, 2022 at 8:36
  • Using a password to gain privileged access does not really add any layer of security. Obtaining the password entered over SSH is trivial if the unprivileged account is compromised.
    – larsch
    Commented May 28, 2023 at 12:28
1

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

Improve this answer
1
  • Yes, I'm very firm on using keys instead of passwords. Actually, when you mentioned passwords, the only benefit I can think of for a regular user is having a separate, root password and requiring it on sudo - so even if your regular user and password are compromised, you'd still need the actual root pw. BUT, I think this is getting a bit on the paranoid side.
    – alex.b.bg
    Commented Feb 20, 2022 at 18:54
1

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.

Improve this answer
6
  • 2
    "significantly less secure" - I'm trying to understand, technically, why this would be the case. From the answers I read to similar questions, and the answers here, the security implications are more on the audit trail/fine grained permissions side rather than a technical difference - of course, for a big company, or even a server that is accessed by multiple maintainers, it makes sense to have an account for each person. BUT, in a case where it's your own machine - say personal vps, home lab, I'm trying to find out if there's a difference if you're the sole admin.
    – alex.b.bg
    Commented Feb 20, 2022 at 19:03
  • 1
    re: "However, the larger your company is, the more serious they will take security.", if you are a tiny little business or a one person Op who can't afford to have dedicated security resources or are simply not aware of the risks, no one will take any sympathy when your IT infrastructure is compromised and your business is ruined. Malicious actors will not think, "Oh, that's small business, I'll avoid compromising them for my own gain 'cos I'm a sympathetic hacker". "It's far more convenient to leave my house door unlocked than fumble for my keys when returning w/groceries"; should you?
    – Ian W
    Commented Feb 21, 2022 at 2:05
  • 3
    I side with @madacoda here: It is up to your paranoia level. Do you want to mitigate exploits through the software (or hardware!) you use? Do you want to thwart automated attacks? Do you want to prevent physical attacks? Who is your attacker? Basically you do a regular vulnerability assessment and act accordingly. A yearly penetration test carried out by a third party provides you with feedback. Purely technically speaking, there is no intrinsic benefit in having different users at all.
    – Kai Burghardt
    Commented Feb 22, 2022 at 2:19
  • @KaiBurghardt "Purely technically speaking, there is no intrinsic benefit in having different users at all." - actually that's exactly the context of the question, whether there's a technical difference that closes any potential vulnerabilities. From the answers here, I do see it's pretty hard to separate this small detail from the overall context of security, but it's good to see that several people agree around what you said. Given you're using a password-protected key, the only benefit of a proxy user seems to be the obfuscation of the username you log in with.
    – alex.b.bg
    Commented Feb 23, 2022 at 1:55
  • 1
    @alex.b.bg: My (and @madacoda’s) point is, it is up to your “definition of vulnerability”. Having different users is a possible means to prevent/thwart certain “attacks”, but if you do not recognize such scenarios as a potential problem for you, taking the measure “user management” is merely a reason of inconvenience. You know, if everybody in the world was friendly, nobody was doing any harm to anyone, there would be no justification for having distinct user accounts with different privilege levels.
    – Kai Burghardt
    Commented Feb 23, 2022 at 2:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .