Why disable ssh login with root on a server if I only log in with keys, not password?
from Sandal6823@sh.itjust.works to linux@lemmy.ml on 12 Apr 2025 08:55
https://sh.itjust.works/post/35979240
from Sandal6823@sh.itjust.works to linux@lemmy.ml on 12 Apr 2025 08:55
https://sh.itjust.works/post/35979240
On a server I have a public key auth only for root account. Is there any point of logging in with a different account?
threaded - newest
Nope, not really. The only reason ppl recommend it is, because “you have then to guess the username too”. Which is just not relevant if you use strong authentication method like keys or only strong passwords.
Don’t quit your day job.
Most comments here suggest 3 things
An actual person from the pen testing world: youtu.be/fKuqYQdqRIs
That is absolutely not the reason ANYONE recommends it, unless you are a complete noob and entirely unfamiliar with computer security at all, and are just pulling assumptions out of your ass. Don’t fucking do that, don’t post with confidence when you’re just making shit up because you think you know better. Because you don’t.
If there is a vulnerability in SSH (and it’s happened before), attackers could use that to get into root directly, quickly, and easily. It’s an instant own.
If root login is disabled, it’s way less likely that whatever bug it is ALSO allows them to bypass root login being disabled. Now they have to yeah, find a user account, compromise that, try to key log or session hijack or whatever they set up, be successful, and elevate to root. That’s WAY more work, way more time to detect, to install patches.
If the effort is higher, then this kind of attack isn’t going to be used to own small fry servers; it’s only be worth it for bigger targets, even if they’re more well protected.
If you leave root enabled, you’re already burnt. You’re already a bot in the DDoS network.
And why? You couldn’t be bothered to type one extra command in your terminal? One extra word at the start of each command?
Sorry bitch, eat your fucking vegetables
Yes it’s always better to login with a user and sudo so your commands are logged also having disable passwords for ssh but still using passwords for sudo gives you the best protection
Sudo also allows for granular permissions of which commands are allowed and which aren’t.
Also double check that sudo is the right command, by doing
which sudo. Something I just learned to be paranoid of in this thread.Unless
whichis also compromised, my god…which sudowill check$PATHdirectories and return the first match, true. however when you typesudoand hit enter your shell will look for aliases and shell functions before searching$PATH.to see how your shell will execute ‘sudo’, say
type sudo(zsh/bash). to skip aliases/functions/builtins saycommand sudomeh nvm none of these work if your shell is compromised. you’re sending bytes to the attacker at that point. they can make you believe anything
Maybe if you escaped the command like
\\type sudo?You assume the shell isn’t compromised.
no, if the attacker can change files in your account, they can read every byte you type in and respond with anything, including pretending to be a normal shell. im not sure how to prevent ssh from running commands in your shell
I never login with the root account. Not even on the console. You don’t want everything you do running as root unless it is required. Otherwise it is much easier for a little mistake to become a big mess.
It’s another slice of Swiss cheese. If the user has a strong enough password or other authentication method through PAM, it might stop or hinder an attacker who might only have a compromised private key, for example. If multiple users have access to the same server and one of them is compromised, the account can be disabled without completely crippling the system.
Using
sudocan also help you avoid mistakes (like accidentally rebooting a production server) by restricting which commands are available to the user.If ssh has a security issue and you permit root logins then hostiles likely have an easier time getting access to root on the machine than if they only get access to your user account—then they need multiple exploits.
Generally you also want to be root as little as possible. Hence sudo, run0, etc.
“Best practices” tend to come from other people’s whoopsies. But it’s always good to question things, too.
Audit trails
Its a concept called defense in depth. Without root login now you require the key AND sudo password.
Also, outside of self hosted you will have multiple people logging in. You want them to log in with their own users for logging and permission management.
The sudo password can be easily extracted by modifying the bashrc.
And who is going to edit your .bashrc?
The attacker that is currently with user privileges on the server?
How did the attacker gain your user’s privileges? Malware-infected user installation? A vulnerability in genuine software running as your user? In most scenarios these things only become worse when running as root instead.
The scenario OC stated is that if the attacker has access to the user on the server then the attacker would still need the sudo password in order to get root privileges, contrary to direct root login where the attack has direct access to root privileges.
So, now i am looking into this scenario where the attack is on the server with the user privileges: the attacker now modifies for example the bashrc to alias sudo to extract the password once the user runs sudo.
So the sudo password does not have any meaningful protection, other then maybe adding a time variable which is when the user accesses the server and runs sudo
Oh that’s dastardly
Simple solution is to not use sudo.
Sorta like Slackware’s default.
And what do you suggest to use otherwise to maintain a server? I am not aware of a solution that would help here? As an attacker you could easily alias any command or even start a modified shell that logs ever keystroke and simulates the default bash/zsh or whatever.
$ su -
And how would you not be able to hijack the password when you have control over the user session?
You would have to know the root password.
With aliases in the bashrc you can hijack any command and execute instead of the command any arbitrary commands. So the command can be extracted, as already stated above, this is not a weakness of sudo but a general one.
You would have to KNOW the root password.
No you can alias that command and hijack the password promt via bashrc and then you have the root password as soon as the user enters it.
As root:
Anything else?
There are many ways to harden against it, but “just disable root auth” is not really it, since it in itself does not add much.
??
Seriously - if you’re “advising” on linux best practices, get lots of liability insurance.
So, you learned about .bashrc today, and you’re now an expert?
Perhaps stand down and let the experts have their say.
No, that’s not how it works.
You really should stop talking shit about things you know nothing about.
Truly sad.
Nah just set up PAM to use TOTP or a third party MFA service to send a push to your phone for sudo privs.
…and if you don’t have your phone attached to your hand…?
I…I don’t understand the question.
Also, yubikey or any other token. Plenty of MFA options compatible with sudo.
Then you can’t gain root privileges on your server. Are you really arguing for less security because it’s inconvenient?
This is end-user behavior and it’s honestly embarrassing. You should realize your security posture is much more important than “I left my phone on the other room”
This thread is embarrassing,
The person you’re responding to could wipe your ass with a cli.
ffs…am I dealing with children here?
You’ve accessed your server as a user, and then you su - to root.
You don’t need a phone or a yubi or a dreamcatcher, or a unicorn.
Please stop with your pretension.
You’re so far out of your league that it’s embarrassing to me that I’ve bothered to answer.
There must at least be MFA somewhere on the path then.
Even just keys, I wouldn’t trust, unless they are stored on smartcards or some other physical “something I have”, require a PIN/passphrase. and centrally managed so they can be revoked and rotated. Too many people use unprotected SSH keys.
that’s why root owns my .bash* stuff
I don’t think that actually works; the attacker could just remove .bashrc and create a new file with the same name.
you’re right. that’s something i wanted to look into. guess setfacl would do the trick?
“chattr +i” is what I use to make things immutable
thanks
.
If the .bashrc is immutable, the attacker can’t remove it.
That’s how it works.
The home directory would need to be immutable, not bashrc.
?
It’s .bashrc, not bashrc, and .bashrc is in the home directory.
If .bashrc is immutable, it can’t be removed from home.
It’s the directory that needs to be writable to delete files, not the file itself.
Although the immutable bit (if that’s what you’re talking about - I thought you meant unsetting the write bit) might change that, I’m not sure.
This was downvoted, but is a good question.
If your account is compromised, the shell init code could be modified to install a keylogger to discover the root password. That’s correct.
Still, that capture doesn’t happen instantly. On a personal server, it could be months until the owner logs in next. On a corporate machines, there may be daily scans for signs of intrusion, malware, etc. Either way, the attacker has been slowed down and there is a chance they won’t succeed in a timeframe that’s useful to them.
It’s perhaps like a locking a bike: with right tool and enough time, a thief can steal the bike. Sometimes slowing them down sufficiently is enough to win.
@ShortN0te @truthfultemporarily What does sudo have to do with ssh keys?
Doesn’t even have to be the key necessarily. Could get in via some exploit first. Either way taking over the machine became a 2-step process.
you would need 2 different exploits for 2 different types of attack though.
its always good to have an extra layer of “oh shit i need another exploit”. unless your threat modelling includes nation-states, that is.
At which point you should have a handful of extra layers
You can disasble passwords so ONLY keys work, and you can firewall ssh to ONLY IPs you originate from.
Just don’t forget to check if your IP has changed if ssh suddenly starts timing out with no error indication no matter what you do and oh god what is actually wrong
I think there’s a way to setup an alert for this.
Or use port-knocking.
The multi-tennant approach to the linux operating system isn’t just for security. It’s the way the OS was designed to operate. You’re not meant to use root as an ordinary user.
Disabling root removes the safety net, but it also plugs the security hole that leaving root enabled leaves.
One always minimises attack surfaces and the possibility of fat fingered mistakes. The lower privileges that you grant yourself the better.
You’d think that Dave Cutler who, I believe, designed Windows NT coming from a Unix style background would have followed these principles but no. I discovered *nix late sadly.
Lots of self-important, irrational, hand-wavy responses to this question as usual.
Assuming you are the only user (sounds like it) and you secure your client device properly, then no, there is no reason not to do what you propose. Go ahead and do it, you’ll save yourself lots of redundant typing and clicking.
Others here can keep performing their security theater to ward off the evil spirits.
This is terrible advice.
“Just turn off your firewall bro, please bro, everyone just paranoid please bro enable remote root login bro 😢”
That’s not what I advised at all.
Well, with root enabled, the SSH server at least need to verify the key, no? It’s wasting CPU power albeit tiny amount.
Zero-day exploits are security holes that exist and are used by bad actors, but aren’t yet known to you, or anyone capable of closing the hole. The clock to patch the hole doesn’t start running until the exploit is known: it stands at zero days until the good guys know it exists.
What zero-day exploits exist for ssh?
By definition, you don’t know. So, you block root login, and hope the bad actor doesn’t also know a zero-day for sudo.
That server’s root access is now vulnerable to a compromise of the systems that have the private key.
Only the server should have the private key. Why would other systems have the private key?
The client has the private key, the server has the corresponding public key in its authorized keys file.
The server is vulnerable to the private key getting stolen from the client.
it is also vulnerable to whatever ssh exploits that can bypass the key
Finding an exploit in ssh is worth more than whatever your server has to offer though.
thats a good point. unless you forget to update it in a timely manner.
that includes most servers out there ime, so
For ssh they both have private and public keys. The server could be at risk of having it’s own private key compromised if somebody breaks in, and vice versa a compromised client can lose its private key. The original wording made it sound like a compromised server would steal client keys.
Also passworded keys are recommended
.
It’s just another way of minimizing your attack surface. It’s pretty much the same as hiding behind a barrier when being shot at, you stick yourself out as little as possible.
In the same way it also helps to change your SSH port to somewhere in the high numbers like 38265. This is anecdotal of course, but the amount of attacks on SSH went down by literally 99% by just changing the port like that
Then you accept only keys, you lock down root (so the username must be guessed as well) and yeah, you’re safe.
Not just anecdotal. The default SSH port gets hit by ridiculous numbers of bots because a lot of people don’t bother to change it. This will be true no matter what machine you’re on. Hell, your desktop at home has probably been scanned quite a few times even if all you do is watch porn on it
A door with the best lock possible is still not as secure as no door at all
When you edit & save a file as root, root takes ownership of that file. I personally don’t like having to run chmod or chown every time I make minor changes to something.
No, that’s not correct. If you create a new file as root, it will own that file. But editing an existing file doesn’t change the owner or group of that file.
It’s a bad practice to log in as root even for administrative tasks. You need to run numerous commands, some of hem can be potentially dangerous while not requiring root privileges. So normally you have an
adminuser in thesudo/wheelgroup and need to login to this account. Also, this adds some protection in case your key has leaked.It’s rarely a good idea to log in as root, doubly so if it’s a system with sensitive data or services that could easily be disrupted accidentally. And even more important if multiple users log in. How will you know who broke things to teach them if they don’t log in first. The only time I log in to any system as root other than a test system is when I need to sftp to access files or some other system that doesn’t have a way to elevate permissions.