100
Why disable ssh login with root on a server if I only log in with keys, not password?
(sh.itjust.works)
this post was submitted on 12 Apr 2025
100 points (96.3% liked)
Linux
53032 readers
382 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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
Simple solution is to not use sudo.
Sorta like Slackware's default.
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...?
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.
I...I don't understand the question.
Also, yubikey or any other token. Plenty of MFA options compatible with sudo.
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.
No, that's not how it works.
You really should stop talking shit about things you know nothing about.
Truly sad.
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.
So, you learned about .bashrc today, and you're now an expert?
Perhaps stand down and let the experts have their say.
??
Seriously - if you're "advising" on linux best practices, get lots of liability insurance.
Oh that's dastardly
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.
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.
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