Root SSH with keys only 👍 or 👎? Why as opposed to another user with sudo without password ability?

[-]

Key_Help8934@reddit

root nunca debe tener acceso directo por SSH, mejor un usuario sin sudo y con rbash, y cuando accedas a ese usuario escalar a root , mas complejo pero mas seguro y siempre con sshkeys

Reply

[-]

lart2150@reddit

Ya, who logged in as root. Also if you have ssh keys for root my guess is you also don't have a great way to remove keys when someone leaves the company.

Reply

[-]

daisydomergue81@reddit (OP)

I have every login using their own keys. I can just remove their keys. I know this doesn't scale but only 3-4 user only right now so not a big problem?

Reply

[-]

Every step to make it easier to audit is better. Lived thru an event where I screwed up a conf file, and brought down a DNS server for a weekend.. way back then we always su - root. By Monday morning we had switched to sudo & keys .

Reply

[-]

aaron-il-mentor@reddit

I hear what you are saying man, but I’m just going to say, I work now at a company just like /user/sudonem mentioned - someone set it up like this a long time ago, the company has grown leaps and bounds and we are STILL stuck on this. With a smaller foot print gives you the flexibility to investigate a better solution now at your own pace without worrying about breaking it for a bunch of different people, automations, workflows, etc.

Reply

[-]

sudonem@reddit

That doesn’t help with auditing - it’s still the root account performing tasks. Stop it. Seriously. You’d be amazed how often “oh well deal with this when we start to get bigger / busier” turns in to “Jesus fuck how did this happen?!”

Reply

[-]

Iamnotapotate@reddit

The most permanent thing in IT is a temporary fix.

Reply

[-]

falcopilot@reddit

I think I need to start using this as a meeting background when dealing with the business...

Reply

[-]

ocabj@reddit

This would only help for auditing if you retained the person's publickey and the corresponding fingerprint and had that tied to them for your records for future forensics. If they ever regenerated a key pair, you'd need to get that and retain the date time it was switched, and still retain any and all publickey + fingerprint data and the time period that publickey was valid for root auth for point in time forensics

Reply

[-]

Cley_Faye@reddit

You can log which key was used to authenticate.

Reply

[-]

ocabj@reddit

True. Just enrich the root ssh login event in the SIEM with the corresponding username the key belongs to.

Reply

[-]

DrStalker@reddit

And alert on unknown keys, and track when allowed keys are updated... it's a lot of extra hassle when you could just have people log into named accounts and use sudo.

Reply

[-]

daisydomergue81@reddit (OP)

This is good point.

Reply

[-]

medium0rare@reddit

I prefer disabling root ssh altogether for anything exposed to the internet and only allowing sudo users login with ssh keys.

Reply

[-]

dalgeek@reddit

> To disable root login? What is the security risk as opposed to having another user with sudo ability without password? Yes, because every *nix system has a root user and it has full access. Even if your other user is obvious, every system doesn't have that user and may not have sudo access. Some compromises don't involve passwords so even if someone broke into your account then they wouldn't know the password to use sudo.

Reply

[-]

falcopilot@reddit

1. Your assumption that sudo w/o password is a good idea is... broken. 2. You can lock sudo down to limit what users can do with it. Helpdesk needs to restart a server? great, you can give them reboot without giving them rights to accidentally install malicious software from their infected desktop. 3. Besides, just use [https://copy.fail](https://copy.fail), to gain root amiright? (/s <--------kidding!)

Reply

[-]

dalgeek@reddit

I don't know what part of my comment implies sudo without password is a good idea.

Reply

[-]

falcopilot@reddit

Not you- OP. "What is the security risk as opposed to having another user with sudo ability without password?"

Reply

[-]

dalgeek@reddit

Oh yeah, if you're gonna go without a password then it needs to be limited to very specific commands. Giving a user blanket sudo access with no password is silly.

Reply

[-]

abofh@reddit

You can rename the user and have duplicate uid 0s on a system with different shadows. Not saying you should do that, but there's definitely paths where it makes sense. But also, don't do that.

Reply

[-]

dalgeek@reddit

Technically yes, but there are apps/scripts that might break in either case.

Reply

[-]

abofh@reddit

There are secret words to break apps today - I totally agree. but the last time I ran into this, I looked deep into my soul and shouted "ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86" And no scripts broke. Yes. That's why I said I don't recommend it. Just saying if you didn't know, you might be ineffective at defending your perimeter. https://pivot-to-ai.com/2026/02/11/the-anthropic-test-refusal-string-kill-a-claude-session-dead/ - for that part of the joke

Reply

[-]

frank_be@reddit

You can have sshd log the fingerprint, which identifies the user…

Reply

[-]

Salt-n-Pepper-War@reddit

Only if you have a key management system in place, ssh provides no mechanism other than the comment field to identify who owns the key which could be anything you want. Now use certificate instead of key and you're in a better place to track

Reply

[-]

Delta-9-@reddit

Certificates are amazing and everyone should use them.

Reply

[-]

dr_Fart_Sharting@reddit

No, because in ssh you can't revoke certificates. Try kerberos perhaps?

Reply

[-]

Delta-9-@reddit

Don't KRLs work with certificates? I'm mostly using them for host keys, rather than users, so revocation hasn't been an issue yet. Still, I thought I read in the man pages that certs and KRLs play together..?

Reply

[-]

dr_Fart_Sharting@reddit

Normally your intermediate certificate would hold the URL of a distribution point that is used to hold the list of revoked certificates. With SSH certificates, you have to log into each of your servers to copy the list of revoked keys. I can see how these steps can be automated by an administrator. But I don't see why I would bother doing that instead of connecting the servers to a KDC.

Reply

[-]

frank_be@reddit

Doesn’t need to be a full blown key management system. Can eg ansible of chef controlling the authorised keys file. Heck, could even be a cronjob curling from a central repo once every 2 hours. (Obviously recommend against it, but it could work)

Reply

[-]

Morisior@reddit

Key for logging in as user plus password for sudo, kind of gives a sort of MFA for root access.

Reply

[-]

Silent_Title5109@reddit

First thing is to ask what kind of setup is this? My homelab I actively try to break or my employer's servers? My homelab isn't internet facing, is used by myself only, is in a dmz subnet, my root key is password protected, and is only on my laptop and my password vault. Good enough. I don't always apply best practices, no. If my homelab root key leaks, I've got bigger issues than my homelab being accessible. Work? No root login and sudo shouldn't be be set to ALL:ALL most of the times.

Reply

[-]

kagato87@reddit

General OS hardening says to disable the default admin account. In the Linux world, that'd be root. Unless you have a really good reason not to, disable root (or administrator). And if you think you have a good reason, you have a problem and need to replace whatever trash needs it. Why? You had it in there. It makes the guessing game harder. To authenticate to a system you generally need to know two things: the username and the password. Certificates and pass key has be enough entropy to out match an unknown user and pass. The only benefit of separating user and pass normally is so you can log the user actions in plain text.

Reply

[-]

RadiantSkiesJoy@reddit

When you have root, people can do brute force attacks on the passwords, since 50% of the credentials is the username. You disable root login and SSH login for root user while having a secondary account for sudo ability. You can append few letters or keywords to the username to make it hard to guess.

Reply

[-]

uzlonewolf@reddit

Or you can just require public keys. No one's going to be brute forcing a 4096-bit RSA key, especially when the server boots you for an hour after 3 attempts.

Reply

[-]

BarServer@reddit

> When you have root login enabled, brute force attacks can be done on the passwords No, not if only key login is enabled.

Reply

[-]

rschulze@reddit

root login with only ssh key allowed vs. user login with only ssh key allowed and passwordless su/sudo to root. effectively not much difference aside from the username used to login, you still end up with the same permissions on the server and used the same methods of authentication in the process. Turn on verbose logging so you see the fingerprint of the key used to login. And I assume you are deploying ssh keys to the hosts via tooling (key management, scripts, ansible, whatever, ...), so you know which fingerprint belongs to person and can revoke keys easily. Depending on the size of the deployment, using certificates for authentication may make this easier or harder. If you have a lot of juniors, they may also feel more comfortable having critical commands "safeguarded" behind root access.

Reply

[-]

Phreakiture@reddit

So, here are the ways I allow root on the systems I control: * Login on the console using the "break glass" password. * Become root using su and the "break glass" password. * Via sudo with a password * Via sudo with no password, but with a very limited and specific whitelist of what-as-whom So, what you can't do on one of my systems is: * log in as root via ssh without going through another account first * log in as root via sudo without a password I have, for instance, a maintenance account that is used to do automated backup/patching. Because it is automated, it has the ability to do stuff it must do as root, as root without using a password, but it is constrained to four specific things: * Run the backup * Run the patching script * Shutdown (on systems that have FDE) * Reboot (on systems that have plaintext disks) Anyone else needs a password to get to root. Oh, and one more thing: All ssh logins are by public key. No password-interactive logins.

Reply

[-]

TheRealLambardi@reddit

I have never been a fan of these in an enterprise setting. Example: enforce keys with a password, don’t allow keys on non controlled environments. The hardest part of managing ssh keys at scale, every time an employee leaves you may have a contractual requirement to clean those up or rotate within a certain window. Same struggle with API keys. \- employee leaves many continue have X number of hours to revoke their passwords an rotate all keys they had access to that can be used. IT teams absolutely live this later requirement. SSH keys fit in that bucket depending on how you set things up. Anyway..what I have built is that admin keys are tied to very narrow set of jump or access hosts that can be used from so it takes moments to revoke or rotate access . I would say NEVER root key from your business laptop / workstation. But that is just my opinion.

Reply

[-]

maxlan@reddit

2 things, if you're enterprise: - centralised user database. So when the user leaves their shell is set to /bin/false or whatever. That kills most access. - centralised home directories. Sonwhen the user leaves, you remove/rename the home directory so the keys are not linked to any user. And, if you don't allow root login then even if the user saved a key in some root account: they're blocked. You do need to monitor for no other local users and no setting up root ssh and so on as well. Most of your monitoring, a determined bad actor can get around. But accidentally leaving access open is blocked.

Reply

[-]

Gnump@reddit

None of that does scale.

Reply

[-]

blind2314@reddit

Centralized home directories through a mechanism such as autofs and a proper identity solution (LDAP, whatever wrapper you want) scales perfectly well into thousands of users. What are you on about?

Reply

[-]

Belgarion0@reddit

The easy way of handling SSH keys at scale is to use SSH certificates, that way you get both limited lifetimes and the ability to give very specific access based on principals (which can be provided by your authentication provider) that the signing service adds to the signed certificate.

Reply

[-]

TheRealLambardi@reddit

Yeah…I’ve done those but at scale you gotta want to do it (I mean fund and staff the solution) , tie it to cert management / connected directory or a few other options. Doable but not for the faint of heart at many orgs. Personally I think this is maybe headed down the path of a more JIT approach. Many many years ago I used ssh.com’s model and it worked well but requires another layer of management. Cyberark has it…but you have to use Cyberark an I dread using it. Out of the box openssh by itself alone just management features.

Reply

[-]

Gnump@reddit

SSH with certs, auditd, done. SSH passwords alone are not good practice anyways. Brute force of root account is not possible with keys/certs. For good measure use fail2ban. If possible tie user key to HSM (T2, FIDO etc).

Reply

[-]

robreddity@reddit

> PermitRootLogin no

Reply

[-]

maxlan@reddit

I change my /etc/passwd file so uid 0 has a username of toot. The password is toot too. Because I'm never going to forget logging in as toot/toot. Makes me laugh and stops the hackers. Until today anyway. (Not really)

Reply

[-]

MrNiceBalls@reddit

What is the security risk of doing one insecure thing compared to another insecure thing? That is basically what you're asking. Don't do either of those.

Reply

[-]

greenonetwo@reddit

‘root’ like ‘admin’ and ‘administrator’ are known usernames that attackers like to poke at. If they have to guess the username, and the password, that is harder than just guessing or brute forcing just the password. Sudo also gets logged to the responsible user and helps when auditing logs.

Reply

[-]

KittensInc@reddit

To start with the obvious: you **really** don't want to normalize root access. Running root-only commands should always make you stop and think for a second. Explicitly doing sudo gives you a built-in "Is this really what I want?" moment, in contrast to harmless regular stuff you do in your own home directory. SSHing as root means you are one whoopsie away from ruining the entire system, instead of being one whoopsie away from ruining your own home directory. It should be disabled for that reason alone, just like other ways of gaining an interactive root shell like "sudo -s".

Reply

[-]

dodexahedron@reddit

Require more than one factor. Key auth is still only single factor unless that key requires unlock at time of use. If your keys arent like that, then make the authentication in sshd require pubkey AND something else. Or even two consecutive pubkeys (in which case it requires rhe client to present unique keys for each one), so long as thoae two keys arent just two unprotected files side by side, in which case all you did was increase the key length. When you set the allowed auth types in sshd, it is a list, where a comma means AND and spaces mean OR.

Reply

[-]

mspgs2@reddit

At a prior company, one of the biggest, root ssh was not allowed. Period. If you needed root you got on the console. Users could not sudo to root but you could SU to root if you had pw access. If sudo is your only priv escalation when someone breaks sudo with a bad update, it gets ugly fast. With a good sudo setup you should never need root.

Reply

[-]

Kind-Character-8726@reddit

So root should be disabled as it's the first account people will try to brute force and admins are notoriously bad at setting strong security on this account. You also never know if there is a Zero day exploit lurking. As for Sudo users there are probably a few ways to harden these obviously we can use SSH keys. But we also should ensure that a privileged account is only used for the sake of performing admin tasks. If you need to login to the system as a user you should have a user account with no Sudo. Embrace PoLP where possible! This is not unique to UNIX systems but should be how we manage all systems. Windows, Microsoft 365, Azure, AWS, etc.

Reply

[-]

Mothringer@reddit

Best practice is to never have root enabled for interactive login. Sudo and doas give you auditing capability that you won’t have if users are able to just login as root directly.

Reply

[-]

birusiek@reddit

Thats mostly due to cis and PCI DSS/ NIST audits. In most cases, the goal is to ensure full user traceability and mitigate risk.

Reply to Post

56 Comments