Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH as a Sudo Replacement

whynothugo.nl

Post reply on HN
Print view View original

51–60 of 114 posts

Re: SSH as a Sudo Replacement

#51

Post by dingensundso »

alexey-salmin wrote: post #40
kelnos wrote: post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

> Add any sudoers to the wheel group, and there you go: only users that can sudo are allowed to even read the bytes of the file off disk, let alone execute them. That's very sensible, I wonder why it's not the default setup everywhere.

Having a wheel group that is allowed to run any command with su rights is the default setup, but it's not the only one.

I have used sudo a lot of times to allow a specific user to run exactly one command with elevated rights. In those cases they weren't in the wheel group.

Re: SSH as a Sudo Replacement

#52

Post by guerby »

kelnos wrote: post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Except when physically logged in via console you're already using ssh before using sudo.

So the complexity you describe is already there.

sudo removed is one less moving part in the end.

Re: SSH as a Sudo Replacement

#53

Post by inopinatus »

guerby wrote: post #52
kelnos wrote: post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Except when physically logged in via console you're already using ssh before using sudo. So the complexity you describe is already there. sudo removed is one less moving part in the end.

That is a furphy, because both tools are also used non-interactively.

If you forced me to choose one to remove, I’d delete ssh in many cases. Anything production that isn’t bare-metal is a candidate for never allowing a remote terminal. Easiest with cloud instances since they’re almost completely disposable, but many sites still don’t have the stomach/discipline for it.

Re: SSH as a Sudo Replacement

#54

Post by jkhanlar »

alexey-salmin wrote: post #40
kelnos wrote: post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

> Add any sudoers to the wheel group, and there you go: only users that can sudo are allowed to even read the bytes of the file off disk, let alone execute them. That's very sensible, I wonder why it's not the default setup everywhere.

Has anyone prepared a list of distributions indicating the default sudo setup comparing to each other? I'd be interested to see the defaults for each distro as a factor to consider.

Re: SSH as a Sudo Replacement

#55

Post by riedel »

dingensundso wrote: post #51
alexey-salmin wrote: post #40

Earlier quoted context omitted.

> Add any sudoers to the wheel group, and there you go: only users that can sudo are allowed to even read the bytes of the file off disk, let alone execute them. That's very sensible, I wonder why it's not the default setup everywhere.

Having a wheel group that is allowed to run any command with su rights is the default setup, but it's not the only one. I have used sudo a lot of times to allow a specific user to run exactly one command with elevated rights. In those cases they weren't in the wheel group.

Actually retristricting defined commands to defined sudoers should be one of the main use cases of sudo. This could be done as well via ssh config but one would need a lot of keys if you don not want a wrapper (and rewrite sudo all over)

If you are really thinking security, elevating a standard user seems bad practice to anyways. It is rather I guess a way to protect the user to do `rm -rf /` accidentally. On the other end adding an another layer of obscurity is practically adding a bit of security against script kiddies. But if that is of concern one could also rename the sudo binary.

One last thing the SSH trick might be interesting is the portability but in this case I would rather go via a standard TCP socket.

Re: SSH as a Sudo Replacement

#56

Post by Sparkyte »

lmz wrote: post #8
aaaronic wrote: post #2

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…

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.

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.

Re: SSH as a Sudo Replacement

#57

Post by lmz »

hughesjj wrote: post #10
lmz wrote: post #8

Earlier quoted context omitted.

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?

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

Re: SSH as a Sudo Replacement

#58

Post by kelnos »

guerby wrote: post #52
kelnos wrote: post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Except when physically logged in via console you're already using ssh before using sudo. So the complexity you describe is already there. sudo removed is one less moving part in the end.

I don't see how two sshd daemons and two sessions is less complicated.

Yes, removing sudo is one fewer moving part, but sshd is a much larger moving part than sudo. (If you think sudo is a larger moving part than it should be, I'd agree, and you can use doas instead.)

Regardless, the vast majority of my sudo usage is on my local machine, so there's no sshd involved at all.

Re: SSH as a Sudo Replacement

#59

Post by kelnos »

alexey-salmin wrote: post #40
kelnos wrote: post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

> Add any sudoers to the wheel group, and there you go: only users that can sudo are allowed to even read the bytes of the file off disk, let alone execute them. That's very sensible, I wonder why it's not the default setup everywhere.

Probably because there's nothing that says only users in wheel (assuming your OS/distro even has that group; some don't) can sudo. You can grant any user with any group membership access to sudo, either full access, or restricted to only certain commands.

If the package was set up to install /usr/bin/sudo so it was only runnable by members of the wheel group, that wouldn't work.

Re: SSH as a Sudo Replacement

#60

Post by euroderf »

kelnos wrote: post #34

My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…

Pardon my ignorance, but I have to ask for explanation of what the wheel group is and does. I'm aware that this might open a can of worms.
Post reply on HN