SSH as a Sudo Replacement
whynothugo.nl
whynothugo.nl
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
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.
That's very sensible, I wonder why it's not the default setup everywhere.
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.
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.
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.
[0] https://web.archive.org/web/20070603191229/http://www.gnu.or...
Hell, not even GNU distros like GNU Guix, Parabola, nor Trisquel follow RMS' opinions on this anymore.
You need the `i` attribute. But this is filesystem dependent. Anyway protecting the `sudo` binary from package managers is a so-so idea.
On Debian, for example, I have unattended-upgrades set up to automatically install security updates. sudo is reasonably likely to have updates for security reasons.
https://wiki.debian.org/DebianAlternatives
https://www.debian.org/doc/debian-policy/ap-pkg-diversions.h...
So the complexity you describe is already there.
sudo removed is one less moving part in the end.
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.
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.
It's no different to any other user group on linux systems and you could replace the name wheel with admin, freethinker, systemdestroyer or whatever else you wanna call it.
You might not even have wheel anymore; Debian just calls it "sudo" now.
> [from slang ‘big wheel’ for a powerful person] A person who has an active wheel bit. “We need to find a wheel to unwedge the hung tape drives.” The traditional name of security group zero in BSD (to which the major system-internal users like root belong) is ‘wheel’.
> The term was invented on the TENEX operating system, and carried over to TOPS-20, XEROX-IFS, and others. The state of being in a privileged logon is sometimes called wheel mode. This term entered the Unix culture from TWENEX in the mid-1980s and has been gaining popularity there (esp. at university sites).
The ForcedCommand infrastructure.
shameless plug: you can prevent this by https://github.com/bAndie91/tools/tree/master/ssh-groupcomma...
Plain ol’ git is also nice in a pinch.
Whether fighting one particular suid binary worth it, is questionable indeed. But this is good direction. Another modern approach to this problem is run0 from systemd.
"Fedora 40 Plans To Unify /usr/bin and /usr/sbin" (2024) https://news.ycombinator.com/item?id=38757975 ; a find expression to locate files with the setuid and setgid bits, setcap,
man run0: https://www.freedesktop.org/software/systemd/man/devel/run0....
As opposed to running background processes as root...?
This is just mindless dogma at this point. You're going to need something to elevate permissions, and setuid is as good of a scheme as any. ssh or run0 are not magic and just as "vulnerable" as setuid or anything else. Any of these schemes are "security holes" if you abuse it.
When there's a daemon running in the background, the attack surface is more commonly understood. The environment is not under attacker control.
Libraries rarely treat data from socket as "trusted" but often blindly trust environment variables, or stdin/stdout/stderr.
sudo etc. already clear much of the environment. And you're going to want to keep some of it because people expect "sudo foo" to work (which you can't do without PATH).
There's a new tool in systemd, called "run0". Or actually, it's not a new tool, it's actually the long existing tool "systemd-run", but when invoked under the "run0" name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it's *not* in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user's UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY. Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).
One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways.
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.
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.
Also, may I introduce you to the ‘sudo -i’ option.
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.
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.
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.
In practice, maybe not.
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.)
> 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)
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.
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_....
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.
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.
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.
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.
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.
> 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.
That's not certain. sshd is way bigger than sudo, so chances of it having an exploitable bug seem higher.
For less fatal emergencies, I don't see anything that would tie this instance of sshd to tge network.
This approach loses a lot of this fine-grained control, and also relies on trusted keys, which are harder to manage than editing a sudoers file.
To see all the amazing things that sudo can do, I’d really recommend the Sudo Mastery book.
To use SSH as a proper sudo replacement it'd need something closer to posix_spawn as an extension.
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.
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.
If you're going to set a root password, you might as well just do this and if I'm not mistaken it accomplishes everything you want
alias sudo="su -c" alias sudo="su root -c"byw everyone should be using ed25519 or at least 2048+
https://www.usenix.org/legacy/publications/library/proceedin...
Those who ignore Usenix are doomed to repeat it … 20 years later.
Kill it with fire.