Separate sudo account for single-user Linux systems?
März 2026
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Recently I had a brief discussion with a colleague that I should have a second user account on my laptop for doing adminstrative stuff. My usual user account shouldn’t be allowed to run sudo. Instead I should switch to the other account and run sudo stuff there. My first (and also my second) thought was, that nobody has two user accounts on a (non-server) Linux machine used only by one and the same person. The driving idea of sudo is to avoid having a root account, which tends to be a security risk. Instead privileged commands are explicitely run via sudo from within the normal user account.
But then the colleague argued that if someone somehow gets the password of the user account, then the attacker also knows the password for running sudo stuff under that account. With a separate sudo account (with different password!) knowing my normal user’s password wouldn’t enable the attacker to run sudo. That made me think… Sounds like a second account indeed would increase security. But why have I never heard about this strategy? Even searching the internet did not reveal anybody suggesting a separate sudo account.
Eventually, I came to the conclusion the a separate sudo account does not increase security. In the best case it does not do any harm, but implies extra costs for maintaining another user account with config files, backups aso. To some extent it might even decrease security. In this article I share the thoughts which lead to these conclusions.
What this article is not about
Just to be clear: this article is not about having a root user account or better use sudo. It’s about having one user account allowed to use sudo or better have two user accounts, one for everyday work without sudo and another non-root account for administrative tasks allowed to use sudo.
We also do not discuss servers her. There, having separate accounts for admins and normal users, services aso. is a very good idea. Of course, the admin accounts are used for admin tasks only and for nothing else.
Assumptions
To compare both variants, with and without separate sudo user account, we impose following assumptions:
- The machine runs a modern Linux distro, say, Debian.
- The machine is not a server, that is, it does not provide any services accessible from other machines in the company/home network or the internet.
- The machine is used by only one person, which at the same time is the only admin.
- Passwords used for user accounts are not used for any other purposes like online services, mail servers aso.
These assumptions might not apply to every user, but to many, especially to me.
The attack
The attack we want to prevent is that someone steals the user’s password, thus, is able to login to the machine locally (or maybe even remotely due to buggy software/configuration) and can do everything the user could do. This includes:
- stealing the user’s data (documents, images,…),
- encrypting the user’s data,
- installing malwar (for botnets, for preparing a larger attack to the whole network,…).
How to steal the password?
For stealing the user’s password there are basically three possibilities:
- Get access to the system’s
/etc/shadowfile and find a password matching the password hash stored there. - Install a key logger or sniff the password by other means during password input (e.g., observing the user’s key presses with a camera).
- Use some kind of phishing.
Case 1 (/etc/shadow)
The first case is the least relevant one. If an attacker has access to /etc/shadow he or she already has deep access to the system. No further need for getting a user’s password. And even more importantly, if an attacker has access to /etc/shadow, then he or she will brute-force the password of a sudo user, which he or she finds next door in /etc/sudoers.
Case 2 (key logger)
The key logger approach is of more relevance, at least in case of a hardware key logger (for installing a software key logger the attacker already needs access to the system).
If the user has only one (sudo allowed) account and the attacker observes the password, then the attacker can do all kinds of harm to the user (see above).
If the user has a separate sudo user account and the attacker only observes the normal account’s password, then the attacker may still steal and/or encrypt the user’s data. But installing malware is more difficult than in the one account setting.
The question of improved security with a separate sudo user account reduces to the question what’s more likely: that the attacker observes the normal user account’s password or the sudo user account’s password. If the attacker uses a (hardware) key logger, then he or she sooner or later will have both passwords (with a strong tendency to sooner). If the attacker observes the keyboard by other means, then he or she will get the password first that is typed more often (for most user’s this would be the everyday account’s password).
So, here a separate sudo user account may increase security slightly compared with only using one account.
Case 3 (phishing)
If an attacker tries to phish a password he or she will somehow ask the user for the password.
The hopefully unsuccessful attempt to simply phone the user and ask him or her for the password should provide more or less equal chances to obtain the sudo or the normal account’s password (in case of a separate sudo account). On the one hand, asking for the non-sudo user password might be more succesful than asking for the sudo user password, because the user thinks “it’s the less important one, I can give it to the IT guy on the phone”. An the other hand, the user knows, that the sudo user password is needed for doing adminsistrative stuff. Thus, it may sound quite reasonable to him or her that the guy on the phone, identifying as member of the IT department, needs the sudo user password.
For phone phishing, thus, having a separate sudo user account does not seem to increase security.
Another phishing attempt may ask the user to input his or her password to a malicious software or website. If an attacker is able to install such a software, then usually it’s too late and revealing a password does not really matter anymore. But alternatively the attacker may set up a website asking the user for the password. What’s the likelihood to get a separate sudo user’s password this way compared to getting the normal user’s password? This heavily depends on the user. Phishing only works if the user thinks that it’s okay to type the password at that place. If a password is used in many different contexts, it’s more likely that the user types the password in a malicious context than for passwords used in only very few different situations.
So let’s check where we (at least me) use passwords and let’s distinguish between typing the password for getting access to the (everyday) user account and typing the password for doing privileged things. I type my user account’s password several times a day, but only in two situations:
- after rebooting the machine for logging in to my account (once or twice per week),
- for unlocking the screen (10 to 20 times per day).
For administrative (that is, sudo) things I type the password for:
- installing new software or updates in a terminal (several times per week),
- using a graphical partition manager (every few months),
- installing a (not so well supported) printer (two or three times per year),
- changing configuration files in terminal (maybe two times per week),
- changing configuration via graphical interface (every few weeks).
The contexts, in which I type the sudo password are quite diverse (terminal plus different graphical contexts). In contrast, for account access the context is quite clear (login screen plus screen unlock screen, both in fact almost identical). Thus, the chance that I fall for a phishing attack is much higher in case of the sudo password. So in case of a phishing attack, accidentially revealing the login password isn’t the relevant problem. The much more likely situation is that one reveals the sudo password. And here it does not matter whether that’s the password of a separate sudo user account or the same password as used for logging in in the usual one account only setting.
Digging even deeper into user behavior, one may argue that for a separate sudo account the user won’t customize all the UI settings one usually has to adjust to allow for efficient workflows in graphical environments (who cares about colors, fonts aso. if the account is only used few minutes per week?). Thus, things there will always look somewhat unusual, increasing the likelihood for successful phishing attacks. Within the everyday working environment even slight deviations from the usual look and feel will be recognized by the user and (hopefully) make him or her closely check the thrustworthiness of a suspicious looking password prompt.
So for the phishing attack a separate sudo user account does not increase security, but may even decrease security (although only slightly).
Conclusions
The two relevant findings are:
- For a key logger based attack a separate sudo user account may slightly reduce the risk of secretly installed malware.
- A separate sudo user account may increase the risk of a successful sudo password phishing attack slightly.
Taking into account, that a phishing attack has a much higher likelihood than a key logger based attack, the overall security gain of a separate sudo user account is negative, that is, security decreases or remains unchanged in the best case.
If the assumptions stated above are violated, conclusions may be different. For example, if a user uses his or her account password for online services, too, then an additional sudo account might be a good idea (at least as long as that password isn’t used for other purposes, too). So in an environment with many careless users, separate sudo user accounts may be appropriate. But on the other hand, careless users shouldn’t be allowed to do privileged things at all, with or without separate account.