friendica.eskimo.com
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.
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 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
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”
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.
?
It's .bashrc, not bashrc, and .bashrc is in the home directory.
If .bashrc is immutable, it can't be removed from home.
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.
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 which is also compromised, my god…
which sudo will check $PATH directories and return the first match, true. however when you type sudo and 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 say command sudo
meh 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
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
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.
thats a good point. unless you forget to update it in a timely manner.
that includes most servers out there ime, so
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.)