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

31–40 of 114 posts

Re: SSH as a Sudo Replacement

#31

Post by TacticalCoder »

cycomanic wrote: post #18

So what happens if ssh (IIRC correctly in typical configurations it depends on network to start) fails to start at boot? You can't even login at failsave console. What does this actually buy us over sudo or su? Sure you avoid a setuid binary but instead you are now running a network service (even though only connected to a socket) with root priveledges.

As I run a system similar to the one used in TFA I'll give my take...

> So what happens if ssh (IIRC correctly in typical configurations it depends on network to start) fails to start at boot?

I do this for my main desktop. If the worse of the worse happen, I've got backup of everything (we all do right?) and I re-install the system.

What I mean is: what do you do when you SSD is dead? You can't even login at failsafe console either.

In 30 years of using Linux I've have hard disk die on me way more than I had my sshd daemon not starting. The ratio is even a divide-by-zero error.

Arguably if my OS had its sshd daemon randomly not starting, it'd be an indication to me that it's time to move to a more stable OS.

> What does this actually buy us over sudo or su?

Much harder to pull local privilege escalation exploits.

Re: SSH as a Sudo Replacement

#32

Post by TacticalCoder »

CaliforniaKarl wrote: post #27
cycomanic wrote: post #18

So what happens if ssh (IIRC correctly in typical configurations it depends on network to start) fails to start at boot? You can't even login at failsave console. What does this actually buy us over sudo or su? Sure you avoid a setuid binary but instead you are now running a network service (even though only connected to a socket) with root priveledges.

> You can't even login at failsave console. Linux consoles (the ttys that appear over local display or remote-access KVM, or the ttyS* devices that appear over serial ports and IPMI SoL) do not use sudo or su. Those consoles use a program like `getty`, or a window-manager; all those programs are non-suid programs that are started as root. Your system should have a root password set, for logins via console.

> Your system should have a root password set, for logins via console.

TFA says that he's prefixing his password hash with '!', making login with a root password impossible (including at the console).

Hence GP's question.

Re: SSH as a Sudo Replacement

#34

Post by kelnos »

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 there's a bug in it, an unauthorized user might be able to use it for privilege escalation. If that's really the main issue, then you can:

    chgrp wheel /usr/bin/sudo
    chmod o-rwx /usr/bin/sudo
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. This essentially gives you the same access-related security as the sshd approach (the UNIX socket there is set up to be only accessible to users in wheel), with much much much less complexity.

And since the sshd approach doesn't allow you to restrict root access to only certain commands (like sudo does), even if there is a bug in sudo that allows a user to bypass the command restrictions, that still gives no more access than the sshd approach.

If you are worried about your system package manager messing up the permissions on /usr/bin/sudo, you can put something in cron to fix them up that runs every hour or whatever you're comfortable with. Or you can uninstall sudo entirely, and manually install it from source to some other location. Then you have to maintain and upgrade it, manually, of course, unfortunately.

Re: SSH as a Sudo Replacement

#38

Post by kccqzy »

I did something similar a decade ago (well without the UNIX socket bit, but just a separate sshd listening on localhost only and also no need to deal with SCM_RIGHTS). Nothing good or bad came out of it. I simply got bored and didn't bother porting this setup to the next machine.

Re: SSH as a Sudo Replacement

#39

Post by r4indeer »

TacticalCoder wrote: post #28

100 000 times yes: I do something similar and I described that here on HN in a comment / comments in the past! The way I do is a bit different... I'm using a dedicated machine as my physical "SSH console" and that machine is living on a private LAN which is separated from the rest of the machines at home. It's on an unmanaged switch, using ethernet cables (but no trunk). Then the only way to login is using SSH but, h…

Sounds like what you have is similar to the idea of a bastion host, even if not quite the same.

Re: SSH as a Sudo Replacement

#40

Post by alexey-salmin »

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.

Post reply on HN