Hacker News Reader

Comment by fiddlerwoaroof | Hacker News Reader

I don’t really see the benefit of disabling root logon vs. allowing user login + sudo to root, if you only allow login via keypairs. This seems to me to be one of those cases where there might be some theoretical benefits, but those benefits don’t matter in practice.

Edit: I see several other people posted this while I was typing :)

View on HN

I configured it so I can only sudo with my password. So even if someone gets hold of my private key, they'd have to guess my password for sudo access. Also, as someone pointed out you can restrict sudo commands, which is the sensible thing to do.

they'd have to guess my password for sudo access.

SSH to your account, add an alias to sudo in .bashrc (or equivalent for your shell) that records the password in a hidden file before passing it to the real sudo.

Is there a practical way to prevent this kind of attack? Also, what the name for this class of exploitation so I can read more?

Use the absolute path to any */sbin utilities :-)

Doesn't help much. Once the attacker took over the account, nothing you do or see can be assumed to be real.

For example, the attacker could inject a LD_PRELOAD library that redirects execve() calls from /usr/bin/sudo to a fake version of sudo.

You can't LD_PRELOAD on a SUID binary like sudo. That said, I agree with your main point - one should use a different account altogether.

I meant preloading it in the shell. The real /usr/bin/sudo would be never executed, so it wouldn't matter if it's suid or not.

How can you preload in the shell? Isn't it launched by sshd, which you can't configure?

You can't configure which shell is run, but you can usually configure the shell (in ~/.profile or a similar file).

Or, if the server is running Debian, you can set environment variables the .pam_environment file:

https://bugs.debian.org/761600

I don't think .profile runs before the shell is spawned, does it?

The .pam_environment one is interesting, thanks for the link.

You can still exec into a new shell, for example.

I'm not security pro, but I think the best way is to use a separate account that you'd login to directly (on the physical TTY or via SSH) just to run the root commands. Going through your regular account is always more dangerous if you assume it might be compromised.

By the way, this is why Microsoft invented the UAC prompt: rather than a password, which can be intercepted, it generates a window which (presumably) cannot, thanks to User Interface Privilege Isolation.

Well, let me explain to you it then.

It's a little bit of a mix of security through obscurity and security in event of sshd having the vulnerability. It won't save you from a targeted attack but will save from blanket "scan 22 port and try root" attacks.

The same way moving ssh from 22 port to something else helps. If you see someone brute-forcing your root you can dismiss it since it's just someone found open 22 port, but if your actual username is being used in attack then you can detect the targeted attack.

Now having password-less sudo is almost the same as using root.

Reply on news.ycombinator.com