6 ms·

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 alway

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

op00to 2y ago
A big part of sudo is that you should be running individual commands using sudo to increase auditability rather than simply running sudo bash or whatever.
- aaaronic 2y ago
  I can agree with that, though admit to being guilty of using sudo bash far more often than I should. 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.
  - mmh0000 2y ago
    If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed. Also, may I introduce you to the ‘sudo -i’ option.
    - dns_snek 2y ago
      > If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed. 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. https://gtfobins.github.io/#+shell https://gtfobins.github.io/#+shell
    - acka 2y ago
      > eMacs 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.
      - mmh0000 2y ago
        You're correct there! Wrote that up on my tiny Apple device and really couldn't be bothered to correct Apple's spellcheck. Text editing from a 5in touchscreen is very painful.
  - op00to 2y ago
    I sudo bash a lot as well. Some times I regret it when I try to figure out what the hell I did months ago. :)
- kiririn 2y ago
  Auditd and pam_tty_audit can take care of all your auditing needs
  - op00to 2y ago
    Sure! All part of layered controls and reporting.
- dmw_ng 2y ago
  It's comical to see the sudo codebase mentioned in the same breath as increasing auditability here
lmz 2y ago
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.
- hughesjj 2y ago
  ...why not just su then?
  - rpgwaiter 2y ago
    root would need a defined password, which opens up other security concerns
    - akira2501 2y ago
      Even if you allow passwordless su for users in the wheel group?
      - djbusby 2y ago
        Do what!?
      - bdd8f1df777b 2y ago
        That's extremely dangerous. Any software running as a wheel user can escalate privileges willy nilly.
        immibis 2y ago
        they can also access your ssh private keys
        rascul 2y ago
o11c 2y ago
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 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)
- cycomanic 2y ago
  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.
  - kchr 2y ago
    > 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_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication https://docs.redhat.com/en/documentation/red_hat_enterprise_....
fsniper 2y ago
The approach is comparing - Theoretical configuration errors, or theoretical vulnerabilities that may or may not be there with - Having a new daemon running (a new attack surface) which - may also have configuration errors, or vulnerabilities as such - and also removes a few layers of user based authorisation with a single root level 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.
irusensei 2y ago
> How is logging into ssh (sshd) AS root more secure than using sudo? 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.
joveian 2y ago
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.
- jeffhuys 2y ago
  Psst… privilege has no letter D

op00to 2y ago

A big part of sudo is that you should be running individual commands using sudo to increase auditability rather than simply running sudo bash or whatever.

aaaronic 2y ago
I can agree with that, though admit to being guilty of using sudo bash far more often than I should. 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.
- mmh0000 2y ago
  If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed. Also, may I introduce you to the ‘sudo -i’ option.
  - dns_snek 2y ago
    > If ‘sudo’ is properly configured running bash or anything that allows command execution (vim, eMacs, etc) is disallowed. 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. https://gtfobins.github.io/#+shell https://gtfobins.github.io/#+shell
  - acka 2y ago
    > eMacs 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.
    - mmh0000 2y ago
      You're correct there! Wrote that up on my tiny Apple device and really couldn't be bothered to correct Apple's spellcheck. Text editing from a 5in touchscreen is very painful.
- op00to 2y ago
  I sudo bash a lot as well. Some times I regret it when I try to figure out what the hell I did months ago. :)
kiririn 2y ago
Auditd and pam_tty_audit can take care of all your auditing needs
- op00to 2y ago
  Sure! All part of layered controls and reporting.
dmw_ng 2y ago
It's comical to see the sudo codebase mentioned in the same breath as increasing auditability here

lmz 2y ago

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.

hughesjj 2y ago
...why not just su then?
- rpgwaiter 2y ago
  root would need a defined password, which opens up other security concerns
  - akira2501 2y ago
    Even if you allow passwordless su for users in the wheel group?
    - djbusby 2y ago
      Do what!?
    - bdd8f1df777b 2y ago
      That's extremely dangerous. Any software running as a wheel user can escalate privileges willy nilly.
      - immibis 2y ago
        they can also access your ssh private keys
        rascul 2y ago

o11c 2y ago

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

cycomanic 2y ago
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.
- kchr 2y ago
  > 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_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication https://docs.redhat.com/en/documentation/red_hat_enterprise_....

fsniper 2y ago

The approach is comparing - Theoretical configuration errors, or theoretical vulnerabilities that may or may not be there with - Having a new daemon running (a new attack surface) which - may also have configuration errors, or vulnerabilities as such - and also removes a few layers of user based authorisation with a single root level 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.

irusensei 2y ago

> How is logging into ssh (sshd) AS root more secure than using sudo? 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.

joveian 2y ago

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.

jeffhuys 2y ago
Psst… privilege has no letter D