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

81–90 of 114 posts

Re: SSH as a Sudo Replacement

#81

Post by ilius2 »

sham1 wrote: post #68
kmeisthax wrote: post #65

Earlier quoted context omitted.

It's worth noting that the reason why your OS/distro doesn't have or doesn't respect wheel is largely down to RMS opposing it[0], instead favoring people trading the root password around to unauthorized users. [0] https://web.archive.org/web/20070603191229/http://www.gnu.or...

It's also worth noting that the Coreutils `su` is no longer in use by anyone, and that the `su` from the shadow-package absolutely checks for wheel. It's even configurable if you haven't enabled PAM by configuring `SU_WHEEL_ONLY` in your login.defs. And with PAM you configure that via PAM. Hell, not even GNU distros like GNU Guix, Parabola, nor Trisquel follow RMS' opinions on this anymore.

Not all distros use `alias su='sudo -i'`. Ubuntu does. Debian does not. Not sure about others.

Re: SSH as a Sudo Replacement

#82

Post by didntcheck »

I've used ssh to localhost as a hack for a backup-to-external-drive script (using Borg iirc) where I wanted the source reading and backup writing to be done as different users. There may have been a more elegant solution but it worked well enough

Re: SSH as a Sudo Replacement

#83

Post by kchr »

cycomanic wrote: post #29
o11c wrote: post #9

Earlier quoted context omitted.

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

> 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_....

Re: SSH as a Sudo Replacement

#84

Post by kchr »

bogantech wrote: post #21
mise_en_place wrote: post #13

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.

Additionally, you need to rotate and distribute the new root password to all root users when you want to remove access for someone.

Re: SSH as a Sudo Replacement

#85

Post by joveian »

tankenmate wrote: post #75

One issue I see with this is Single User Mode (aka recovery mode in grub (or similar) boot loader). Now you can't login as root to recover from init (systemd) configuration issues without having alternate boot media to get you access. I know it might sound pedantic but I used just this feature two days ago while upgrading a machine to a newer Linux release (the upgrade introduced an issue with the systemd / netplan c…

If you want traditional single user mode that drops you to a root shell even though your root account is locked add SYSTEMD_SULOGIN_FORCE=1 to the environment of rescue.service and emergency.service (systemctl edit rescue.service). Of course that exact solution isn't always a good idea depending on the situation but in general that situation can be delt with differently from normal access while running correctly.

Re: SSH as a Sudo Replacement

#86

Post by joveian »

bogantech wrote: post #21
mise_en_place wrote: post #13

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.

You can have multiple accounts with uid/gid 0 (and can set up smart card or u2f login too if you want).

Re: SSH as a Sudo Replacement

#87

Post by joveian »

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 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.

Re: SSH as a Sudo Replacement

#88

Post by tankenmate »

joveian wrote: post #85
tankenmate wrote: post #75

One issue I see with this is Single User Mode (aka recovery mode in grub (or similar) boot loader). Now you can't login as root to recover from init (systemd) configuration issues without having alternate boot media to get you access. I know it might sound pedantic but I used just this feature two days ago while upgrading a machine to a newer Linux release (the upgrade introduced an issue with the systemd / netplan c…

If you want traditional single user mode that drops you to a root shell even though your root account is locked add SYSTEMD_SULOGIN_FORCE=1 to the environment of rescue.service and emergency.service (systemctl edit rescue.service). Of course that exact solution isn't always a good idea depending on the situation but in general that situation can be delt with differently from normal access while running correctly.

Ouch, that's a major security issue if configured that way. That's something I'll want to add to my hardening checks.

Re: SSH as a Sudo Replacement

#89

Post by spydum »

tankenmate wrote: post #76
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…

Personally I use etckeeper[0] to make sure all changes to /etc are tracked, either by software installs / upgrades, or done by humans. It's also great when needing to upgrade a machine to a newer release as you can create a patch file with all your local changes and apply that patch to a clean install and do a three way merge that will highlight all conflicts and keep you up to date and any changes required from one…

such a great idea, i have not seen this before. back in my solaris admin days, we used to keep config stuff version controlled locally like this with rcs; found it super useful for quickly answering "what changed, and how" during incidents (whereas just looking for modified files and fetching backups was a slow ordeal)

Re: SSH as a Sudo Replacement

#90

Post by flakes »

blueflow wrote: post #70
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…

> And since the sshd approach doesn't allow you to restrict root access to only certain commands [...] The ForcedCommand infrastructure.

There's also a command argument that can be provided in the authorized keys setup, which can force connections with a particular key to hit an entry-point application.
Post reply on HN