19

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.

alex.b.bg
  • 133
  • 1
  • 9
  • 1
    If I'm a hacker, I know root will exist on all linux machines, Blocking root (and guest), creating an account "SupremeLeaderSnoke" and giving that account full sudo access is trivial layer of security protection. Now I need to guess both the username AND the password to get in. Now you can get more sophisticated and create multiple accounts that have sudo privileges to specific resources for remote admin tools, that way you again limit the blast radius should someone get in. – Ian W Feb 21 '22 at 02: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ý Feb 21 '22 at 07:46
  • @jakub-luck%c3%bd, but to leverage a sudo fault you already have be on the inside. I did not by any means suggest disabling root access, creating a second account is sufficient security. Also not going to enter into a debate on what's "sufficient". Installing apps apps as root and logging in as root, inevitably the user will always log in a root, even for routine non-root taks. Now you open yourself to even more vulnerability vectors than just sudo. – Ian W Feb 21 '22 at 09:23
  • 2
    There is a third option not mentioned in the question: Using `su` instead of `sudo`, through a proxy account. – marcelm Feb 21 '22 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 Feb 21 '22 at 15:11
  • Mostly has been answered Here: https://serverfault.com/questions/580881/is-it-ok-to-set-up-passwordless-sudo-on-a-cloud-server/581111#581111 – SnakeDoc Feb 22 '22 at 18: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 Feb 22 '22 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 Feb 23 '22 at 01:30
  • @AndrewHenle although I will agree that the argument of sudo getting compromised is deep into paranoid territory, we've seen discovered holes from time to time in critical os components so I don't think we as professionals should treat any piece of software as impeccable :) – alex.b.bg Feb 23 '22 at 02:22
  • 1
    @alex.b.bg Paranoid territory? CVE-2021-3156 was released only a year ago, and it wasn't the only bug that sudo has had. There is also the issue of incorrectly configuring the software. It is a completely valid suggestion to consider the potential issues with just adding sudo to anything. – user Feb 23 '22 at 17:12
  • 1
    @user Yes, paranoid because if you go down that rabbit hole, you can end up with a conclusion that nothing in the universe is secure, including that moment where exactly the critical number of disks in your raid fail at the same time, or more elegantly - the data center catches fire :) Take the log4j hype - a pretty serious drama, the hole being in existence for years - have you heard of an actual attack via these? I haven't. Of course, if you work for NSA, being paranoid is definitely a plus. If you're securing your home NAS - I don't think so. – alex.b.bg Feb 23 '22 at 20:28
  • @user and I'm not saying so much that your personal data isn't worth what NSA has - personally, I give exactly zero dime if the World data disappears compared to my family photos :) But more importantly - the threat actors to a big corporation or agency are vastly different from what could potentially attack your private network. Looking at my fail2ban log for the past 10 years I've only seen one probe that was probably specifically targeted at me. – alex.b.bg Feb 23 '22 at 20:31

9 Answers9

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)

TylerW
  • 556
  • 4
  • 8
  • 2
    Well, that private key should _still_ have a password. – Dubu Feb 21 '22 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 Feb 21 '22 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 Feb 22 '22 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 Feb 22 '22 at 19:14
  • What would prevent the attacker from simply changing your user's password and sudo'ing that way? Taking that route, you can password-protect your ssh key, which I would definitely recommend always, every time anyway, and even further - you can have a separate password for root which you'd be required to input on sudo with rootpwd - this way even if your user is compromised, the attacker won't be able to sudo. BUT, given a password protected ssh key, maybe the above goes into the paranoid land. – alex.b.bg Feb 23 '22 at 01:35
  • Would you like to see what I can do with a compromised ssh key of an administrator's personal account when sudo is in use? – joshudson Feb 23 '22 at 01:42
  • 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 Feb 23 '22 at 02:57
  • @TylerW right, forgot about that. – alex.b.bg Feb 23 '22 at 03:10
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
void
  • 178
  • 9
  • 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 Feb 21 '22 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 Feb 23 '22 at 02:15
  • No, technically there is not a real benefit of a "proxy" user over acting as root. But still, you can implement even more security via sudo, e.g. combine with SELinux or even set your own password prompt. I never used it but I guess that would make it easy to use authentication databases as LDAP for sudo. Most interesting maybe for a single user machine: Integrating TOTP is also possible. – void Feb 23 '22 at 07:01
  • 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 Feb 23 '22 at 07:08
  • Hi @void, only thing missing to make your answer complete is a reference link for "Don't use passwords without keyfiles." on "how-to" keyfiles. – Ian W Feb 23 '22 at 10:55
  • 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 Feb 23 '22 at 12:26
  • @void I would recommend using key passwords no matter where you store them. Leaking private keys happens here and there, and especially if you're using it on several places, it becomes a single point of (security) failure for your whole ecosystem. I think passwordless keys make sense for automated stuff with very limited permissions accounts like a scheduled backup job or some other integration. BTW, I didn't know if you comma-separate several auth methods for sshd, it requires them both :) I've got to try that... – alex.b.bg Feb 23 '22 at 14:01
  • 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 Feb 23 '22 at 14:49
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.

Krackout
  • 1,559
  • 6
  • 17
  • 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 Feb 20 '22 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 Feb 21 '22 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 Feb 21 '22 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 Feb 23 '22 at 01:39
  • If you can ask for emergency boot on the console, the root password is a speed bump, not a barrier. – joshudson Feb 23 '22 at 01: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)

Stig Hemmer
  • 187
  • 3
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).

mak47
  • 151
  • 2
  • 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 Feb 23 '22 at 02: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 Feb 23 '22 at 08: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 Feb 23 '22 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.

Bob
  • 5,335
  • 5
  • 24
  • 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 Feb 20 '22 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.

shearn89
  • 3,143
  • 2
  • 14
  • 39
  • 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 Feb 23 '22 at 01: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 Feb 23 '22 at 08:36
1

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

poggingfish
  • 27
  • 2
  • 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 Feb 20 '22 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.

madacoda
  • 185
  • 7
  • 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 Feb 20 '22 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 Feb 21 '22 at 02: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](https://en.wikipedia.org/wiki/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 Feb 22 '22 at 02: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 Feb 23 '22 at 01: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 Feb 23 '22 at 02:41
  • @KaiBurghardt yup, I asked the question mainly to clear it up for myself if I'm missing something on the technical side. On a practical side, if we're talking about home labs, personal machines, etc, that are behind decent layers of security - like having vpn, isolated from public, etc, I think as an attacker, I'd focus a lot more putting a keylogger on the personal PC where the user types all their passwords than trying to break in to the machines themselves :) – alex.b.bg Feb 23 '22 at 03:18