Live data from Hacker News

SSH as a Sudo Replacement

whynothugo.nl

21–30 of 114 posts

Re: SSH as a Sudo Replacement

#21

This is an elegant solution to the problem. We don't need to treat users as children, but at the same time we should avoid potential foot guns with sensible defaults. I'd argue that even `su` is not needed, if you need to be root, then login as root via console. This is as close as possible to logging into root from the console tty.

> if you need to be root, then login as root via console

1: This requires every user to have the root password, while sudo does not

2: If everyone just logs in as root there's no way to audit who actually logged in and did what.

Re: SSH as a Sudo Replacement

#22

Earlier quoted context omitted.

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

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

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

Re: SSH as a Sudo Replacement

#25

Earlier quoted context omitted.

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

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

they can also access your ssh private keys

Re: SSH as a Sudo Replacement

#26

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 far as I'm concerned, I use setuid/sudo for auditing. At this point, I don't really do multi-user/multi service boxes. Almost everything I have that's multi-tenant at this point is k8s and you can just use kubectl endpoint instead of ssh. But if you're allowed to log in, you're allowed to setuid to root. So for a k8s box, that's the platform infra team and access to the services on top is through the k8s permissions provider.

For the platform infra teams, if you just need something like metrics and logs, that's already off box. If you need to trigger some job or workflow, you can use the pipeline.

But when someone does log in and do root stuff, I want to have an audit log.

I actually can't think of a single box I own where someone with a login doesn't also have root for everything.

Obviously, I understand the services doing setuid thing, but in the case of services, you generally have systemd doing setuid to drop permissions instead of the other way around.

Re: SSH as a Sudo Replacement

#27

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.

Re: SSH as a Sudo Replacement

#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, here's a little spin... with a Yubikey.

The desktop PC has its own firewall, only accepting SSH traffic in from the IP / MAC address of my "SSH console" (on the private LAN it's sharing with the SSH console... On the other physical LAN, my desktop can access the Internet).

Then the sshd daemon is configured to only allow pub/priv key logins, no password logins.

So basically when I need root, I boot up my "SSH console" (which boots ultra quickly for there's basically nothing on that machine), log in, hit the up arrow to get back the "ssh root@..." line, hit enter, press the Yubikey.

That "ssh console" and its keyboard is on my desk, always withing reaching distance.

iptables/nftables (on a private LAN moreover, physically separated from the other private LAN) + sshd: you judge if this is more or less secure than sudo binaries / su.

As to the "why", I'd answer "because I can". I did set that up such a long time ago that I don't even remember when I did. I think I started toying with that idea two years ago and I've been using it ever since. Zero problem. Not a single issue.

Re: SSH as a Sudo Replacement

#29
post #9
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…

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 c…

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.

Re: SSH as a Sudo Replacement

#30

Earlier quoted context omitted.

...why not just su then?

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

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.
Post reply on HN