Why disable ssh login with root on a server if I only log in with keys, not password?
On a server I have a public key auth only for root account. Is there any point of logging in with a different account?
This entry was edited (1 month ago)
Welcome to Friendica.Eskimo.Com
Home of Censorship Free Hosting
E-mail, Web Hosting, Linux Shell Accounts terminal or full remote desktops.
Sign Up For A Free Trial Here
Please tell your friends about federated social media site that speaks several fediverse protocols thus serving as a hub uniting them, hubzilla.eskimo.com, also check out friendica.eskimo.com, federated macroblogging social media site, mastodon.eskimo.com a federated microblogging site, and yacy.eskimo.com an uncensored federated search engine. All Free!
rtxn
in reply to Sandal6823 • • •model used in risk analysis and risk management illustrates that, with layered security, each layer provides protection from certain types of attacks but has weaknesses
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)Nanook
in reply to Sandal6823 • •grrgyle
in reply to Nanook • • •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.
0x0
in reply to Nanook • • •truthfultemporarily
in reply to Sandal6823 • • •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.
ShortN0te
in reply to truthfultemporarily • • •Lemmchen
in reply to ShortN0te • • •ShortN0te
in reply to Lemmchen • • •Lemmchen
in reply to ShortN0te • • •ShortN0te
in reply to Lemmchen • • •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
miss_demeanour
in reply to ShortN0te • • •Sorta like Slackware's default.
ShortN0te
in reply to miss_demeanour • • •miss_demeanour
in reply to ShortN0te • • •ShortN0te
in reply to miss_demeanour • • •slothrop
in reply to ShortN0te • • •ShortN0te
in reply to slothrop • • •So the command can be extracted, as already stated above, this is not a weakness of sudo but a general one.
slothrop
in reply to ShortN0te • • •ShortN0te
in reply to slothrop • • •miss_demeanour
in reply to ShortN0te • • •Anything else?
JasonDJ
in reply to miss_demeanour • • •miss_demeanour
in reply to JasonDJ • • •JasonDJ
in reply to miss_demeanour • • •I...I don't understand the question.
Also, yubikey or any other token. Plenty of MFA options compatible with sudo.
4am
in reply to miss_demeanour • • •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”
miss_demeanour
in reply to 4am • • •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.
JasonDJ
in reply to miss_demeanour • • •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", and centrally managed so they can be revoked and rotated. Too many people use unprotected SSH keys.
WheelchairArtist
in reply to ShortN0te • • •SavvyWolf
in reply to WheelchairArtist • • •2ndSkin
in reply to SavvyWolf • • •That's how it works.
SavvyWolf
in reply to 2ndSkin • • •2ndSkin
in reply to SavvyWolf • • •?
It's .bashrc, not bashrc, and .bashrc is in the home directory.
If .bashrc is immutable, it can't be removed from home.
Nanook
in reply to ShortN0te • •BrianTheeBiscuiteer
in reply to truthfultemporarily • • •☂️-
in reply to BrianTheeBiscuiteer • • •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.
lordnikon
in reply to Sandal6823 • • •grrgyle
in reply to lordnikon • • •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…sludgewife
in reply to grrgyle • • •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
ShortN0te
in reply to Sandal6823 • • •4am
in reply to ShortN0te • • •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
SirMaple__
in reply to Sandal6823 • • •deadbeef79000
in reply to Sandal6823 • • •BCsven
in reply to deadbeef79000 • • •forbiddenlake
in reply to BCsven • • •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.
☂️-
in reply to forbiddenlake • • •x00z
in reply to ☂️- • • •☂️-
in reply to x00z • • •thats a good point. unless you forget to update it in a timely manner.
that includes most servers out there ime, so
HiddenLayer555
in reply to Sandal6823 • • •