Hacker News Reader

Comment by aaaronic | Hacker News Reader

Am I missing something?

How is logging into ssh (sshd) AS root more secure than using sudo? I honestly don’t even know how dangerous that is because I’ve always been told to never allow it. I see here thought goes into preventing that for a remote user, so I’m not talking about that aspect of security here.

Maybe it has to do with #3 in the sudo limitations — I certainly don’t see any benefits vis-a-vis #1.

I totally get that this is an experiment, but I suspect it is more vulnerable than using sudo, not less (the open socket proxy looks interestingly vulnerable to a man in the middle attack).

Having said all that, I did learn some tricks old tools are capable of, so kudos for showing me something new.

View on HN

The sudo binary is suid root / privileged and is exposed directly to the untrusted user. If anything goes wrong inside of sudo (with the user's entire environment as the surface area), it may be exploited.

The ssh approach does not expose a suid binary. Instead it uses the ssh network layer so it is no less secure than accessing ssh over a network, which is considered pretty secure.

...why not just su then?

root would need a defined password, which opens up other security concerns

Even if you allow passwordless su for users in the wheel group?

Do what!?

That's extremely dangerous. Any software running as a wheel user can escalate privileges willy nilly.

they can also access your ssh private keys

In theory, those ssh private keys are password protected.

In practice, maybe not.

They were stored in the user’s yubikeys (or similar) in this example.

If you do that you deserve what you get

plzno

We've got root passwords set on, IIRC, all of our systems. They're long, random, and can only be entered through the console on the VGA port or the IPMI console.

su is also a suid binary, no? It is probably a lot less complex than sudo.

I would assume if you has to use SSH or sudo you've already lost. I've been working with people where we just completely lock down the VM or Container. They only allow necessary flow of traffic and are managed entirely from golden builds. If you need to make changes or fix something it is a new vm or container.

This premise is incorrect: SSH doesn't need to be an suid binary because it's already running as root, and then SSH creates a new environment for the user, exactly like sudo does, but with all the added complexity and overhead (and surface) of privileged network access.

To be clear, I love SSH and we even run a userify instance to distribute keys, but juts comparatively the surface area of the ssh daemon alone is greater than sudo alone.

(however, even with the extra complexity, you might trust the history of portable OpenSSH more than sudo, and that's a good, but different, conversation to have also.)

But the area under control by the invoking user is data over one socket vs the whole calling environment e.g. environment vars, local files. Surely that counts for something.

Unfortunately SSH has to do all that too. :(

A big part of sudo is that you should be running individual commands using sudo to increase auditability rather than simply running sudo bash or whatever.

I can agree with that, though admit to being guilty of using sudo bash far more often than I should.

I honestly thought they’d be using ssh that way (single command at a time), though I’m still not sure to what security end.

If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed.

Also, may I introduce you to the ‘sudo -i’ option.

> If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed.

Keep in mind that this is borderline impossible to enforce unless your goal is just to stop the most common ways of accidentally breaking the policy. A list of commands that allows breaking out into a full shell includes: less, apt, man, nano, wget & many more.

https://gtfobins.github.io/#+shell

> eMacs

This made me chuckle. Apple influencing the way Emacs is capitalized (pun intended) versus RMS's stance on Free Software couldn't be further apart I think.

You're correct there! Wrote that up on my tiny Apple device and really couldn't be bothered to correct Apple's spellcheck. Text editing from a 5in touchscreen is very painful.

I sudo bash a lot as well. Some times I regret it when I try to figure out what the hell I did months ago. :)

Auditd and pam_tty_audit can take care of all your auditing needs

Sure! All part of layered controls and reporting.

It's comical to see the sudo codebase mentioned in the same breath as increasing auditability here

> How is logging into ssh (sshd) AS root more secure than using sudo?

Article describes an additional SSH server listening on an Unix socket. The usual threat model about exposing root logins from the internet may not apply here.

The approach is comparing - Theoretical configuration errors, or theoretical vulnerabilities that may or may not be there with - Having a new daemon running (a new attack surface) which - may also have configuration errors, or vulnerabilities as such - and also removes a few layers of user based authorisation with a single root level

This approach is somehow considered more secure.

And in a rational way, and of course for any rational security perspective this can't be considered more secure, just different.

I'm skeptical of the approach in the linked article, but:

> I honestly don’t even know how dangerous that is because I’ve always been told to never allow it.

You've fallen for the FUD. In reality, logging in directly as root over remote SSH is strictly more secure than logging in as user over remote SSH and then using `sudo`.

If user@home uses ssh to root@server, then root@server is only compromised if user@home is compromised.

If user@home uses ssh to user@server then sudo to root@server, then root@server is compromised if either user@home or user@server is compromised. In particular, it is fairly common for user@server to be running some other software such as daemons or cronjobs. Please don't give out free root escalation (and often lateral movement due to password reuse) to anyone who manages to infect through those!

(This of course does not apply if sudo is used in whitelisted-commands-only mode and does not take either passwords or credentials fully accessible from the remote host)

I'm not sure I agree with this argument. Sure you can say theoretically it's one less account that could be compromised, but in practice I see a bunch of caveats.

1. If we allow password based logins, there will be many orders of magnitude more login attempts to root than any other user. So if you have to allow password based logins, you pretty much never want to allow root login.

2. If we disallow password based logins, a user account would be as save as a root login, except again that the root account is the much more valuable target so will get much more attention. I also do see the relevance of cronjobs (root does run them as well) and naturally no user that has sudo privileges should be be running network exposed services.

3. In cases were admin rights have to be shared amongst multiple users, are you going to share the same key for all users (probably not a good idea) or give every user a separate key (making key management a bit of a nightmare, user management is much easier).

4. As you pointed out yourself sudo gives you much more fine-grained control over commands that can be run.

> 3. In cases were admin rights have to be shared amongst multiple users, are you going to share the same key for all users (probably not a good idea) or give every user a separate key (making key management a bit of a nightmare, user management is much easier).

To solve the key management nightmare, short-lived SSH certificates can be used to map an identity to a shared user account. Hashicorp Vault is one option for issuing such certificates, but there are other alternatives as well.

https://docs.redhat.com/en/documentation/red_hat_enterprise_....

The big advantage is if setuid and setgid support can be entirely removed. There are a bunch of special cases that have been added over the years to try to deal but increasing priviledges of a process is fundamentally more challenging in the unix security model than only ever lowering priviledges. Of course these days Linux has priviledge escalation via user namespaces as well.

Psst… privilege has no letter D

Reply on news.ycombinator.com