On a server I have a public key auth only for root account. Is there any point of logging in with a different account?
- Swiss cheese slices: make them holes too tight.
- When you run everything as root, if you fuck your shit, your shit’s fucked.
“Best practices” tend to come from other people’s whoopsies. But it’s always good to question things, too.
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.
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.
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
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 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.
Oh that’s dastardly
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…
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.
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.
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.
Audit trails
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.
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.
Well, with root enabled, the SSH server at least need to verify the key, no? It’s wasting CPU power albeit tiny amount.
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.
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
- least privilege: Which is ok, but on a Server any modification you do requires root anyway, there is usually very little benefit
- Additional protection through required sudo password: This is for example easily circumvented by modifying the bashrc or similar with an sudo alias to get the password
- Multiuser & audittrails: yes this is a valid point, on a system that is modified or administered by multiple ppl there are various reasons lime access logging and UAC for that
An actual person from the pen testing world: https://youtu.be/fKuqYQdqRIs
