10 ms·

For some more serious alternatives, I have heard of many people finding doas to be a drop in replacement. Furthermore, I've heard some people suggest neither do

For some more serious alternatives, I have heard of many people finding doas to be a drop in replacement. Furthermore, I've heard some people suggest neither doas nor sudo, but instead using an SSH server to gain root access to your local machine. It could listen on localhost and use key-based auth to allow root logins...

zamadatix 4y ago
I used the SSH server method for a while on a Windows machine since it's built in Terminal doesn't support mixed security contexts between tabs/panes.
augusto-moura 4y ago
I did use ssh on localhost to do some X11 trickery once. It works surprisingly well
AtlasBarfed 4y ago
Except the enterprise security industry is waging war on ssh keys and ssh/sshd.
- themikesanto 4y ago
  Interesting. Could you expand on that, or point me towards some related reading? Thanks!
- arp242 4y ago
  What's wrong with ssh keys? Or ssh/sshd for that matter?
  - xena 4y ago
    The main problem with SSH keys is that they are good at small scales, but at larger scales the abstractions start to be really leaky. Distributing SSH keys across hundreds of machines is a nontrivial task. Not to mention the lack of audit logging in opensshd and the lack of session recording (these requirements suck but acronym compliance means you need them anyways). It's also kind of the wrong tool for the job anyways. I'd love to see tools that are more built to purpose for what you are _actually doing with the servers_ instead of giving people a REPL and telling them to go nuts.
    - toast0 4y ago
      > It's also kind of the wrong tool for the job anyways. I'd love to see tools that are more built to purpose for what you are _actually doing with the servers_ instead of giving people a REPL and telling them to go nuts. On the other hand, if you knew what I'd need to do with the servers, I probably wouldn't need to do it. It's really hard to investigate problems without tools. Nobody is going to make a graph for how much cpu poorly configured docker/datadog are wasting rereading the same 1GB of json logs once or twice a minute, because nobody thought it would be meaningful, but watching top in one window, and running lsof at the right time to see what's being read, and whatever performance tools are hanging out to confirm.
      - AtlasBarfed 4y ago
        Ah the dream of easy to administer, perfectly adapted fine grained access permissions that can predict the future of exactly what an authorized user can run and needs to do. It never works because of the lack of precog, ticket walls, escalation over policy requiring reviews, and other bureaucracy. What they end up replacing ssh with (teleport or aws ssm are the two I've been forced to use) are slow, spotty, crash frequently, and who knows what vulnerabilities they have. If all these companies trying to get rid of sshd want to slap their own daemon on to replace it, why not keep sshd and simply have a deamon that manages the keys and not throw out the entire tool chain? The most fun thing with teleport and aws-ssm: to use it you had to bring up a web page to authenticate. There goes any hope of automation at scale. Because in a world where you're supposed to treat servers like cattle, let's impose (and I mean impose) a regime that forces you to access them one at a time manually, especially in critical situations.
    - imiric 4y ago
      > Distributing SSH keys across hundreds of machines is a nontrivial task. SSH certificates are a thing.
      - xena 4y ago
        Now you have two problems
- wkat4242 4y ago
  In the enterprise key management can become a bitch really quickly. Good luck updating 10.000 servers every time an admin leaves. For them ssh certificates are much better because you can simply revoke them, and new certs don't have to be added to each server. At home I still use keys though, but as an enterprise admin I see the issues. Even at home it's kinda annoying having to add a new yubikey to 20 servers.
  - hobobaggins 4y ago
    Unless you use something like Userify. It's like my secret tool that no one knows about..
  - janc_ 4y ago
    You could use AuthorizedKeysCommand or some other method to manage your keys in one central place.
    - wkat4242 4y ago
      You can, but you still need to set up a secure infrastructure to manage all the requests going back and forth. And most enterprises already have a completely functional and secured PKI, usually with the whole HSM deal and everything. It's plug and play and works with your existing infra.
  - still_grokking 4y ago
    > In the enterprise key management can become a bitch really quickly. Good luck updating 10.000 servers every time an admin leaves. Can't "jump host" solve this? (Not an admin, so please excuse if the question is stupid).
    - xena 4y ago
      No
  - account-5 4y ago
    You have 20 servers at home? What's you electrical bill like?
- StreamBright 4y ago
  It is not as much the enterprise security industry as it is better security for all. Problem with the current implementation with ssh keys is that there are non-trivial problems with it. For example how do you revoke a key? It is not possible in a central AAA service to revoke access for a user like it is possible for other kind of auth systems. Ssh and ssh keys were designed in an era where security was not really the primary concern. I think Facebook DevOps team had some detailed article how they manage ssh access to fb production with keys.
  - CameronNemo 4y ago
    There is so many things wrong with your comment it is not even worth explaining.
mid-kid 4y ago
Using key-based auth without encrypting the key with a password sounds like a bad idea, as then any program running on the host can trivially gain root privileges.
- remram 4y ago
  Any program running as your user on your personal machine can trivially gain root privileges, by dropping a program called "sudo" in your personal PATH, putting a "sudo" command in your .bashrc, man-in-the-middle a shell (how do you know that last command actually completed?), or hijacking any of the graphical programs that trivially ask you for your UNIX password to do anything (Discord/Slack/... updater, Steam, ...)
  - pxc 4y ago
    When do any of those programs ask you for your password? I've never had any of them ask for my Unix password, ever. Is that just a macOS thing with self-updaters?
    - remram 4y ago
      I'm using Ubuntu/KDE/Plasma. "Discover" is the GUI app that prompts you to install system updates, and will ask for your password when you do (to run apt/dpkg as root). Discord doesn't directly ask for my password, it downloads a .deb from somewhere and opens it, and I get prompted for my password then. Not much different IMHO.
      - still_grokking 4y ago
        I'm using Debian(Testing)/KDE/Plasma. (What was the point here?) I don't have any "Discover" installed as it's not needed for anything. There's aptitude… Regarding Discord: Discord is a virus. I try to avoid it. (And since you can't register without getting naked and showing the virus your telephone number it's not difficult to avoid ;-)).
        4y ago

zamadatix 4y ago

I used the SSH server method for a while on a Windows machine since it's built in Terminal doesn't support mixed security contexts between tabs/panes.

augusto-moura 4y ago

I did use ssh on localhost to do some X11 trickery once. It works surprisingly well

AtlasBarfed 4y ago

Except the enterprise security industry is waging war on ssh keys and ssh/sshd.

themikesanto 4y ago
Interesting. Could you expand on that, or point me towards some related reading? Thanks!
arp242 4y ago
What's wrong with ssh keys? Or ssh/sshd for that matter?
- xena 4y ago
  The main problem with SSH keys is that they are good at small scales, but at larger scales the abstractions start to be really leaky. Distributing SSH keys across hundreds of machines is a nontrivial task. Not to mention the lack of audit logging in opensshd and the lack of session recording (these requirements suck but acronym compliance means you need them anyways). It's also kind of the wrong tool for the job anyways. I'd love to see tools that are more built to purpose for what you are _actually doing with the servers_ instead of giving people a REPL and telling them to go nuts.
  - toast0 4y ago
    > It's also kind of the wrong tool for the job anyways. I'd love to see tools that are more built to purpose for what you are _actually doing with the servers_ instead of giving people a REPL and telling them to go nuts. On the other hand, if you knew what I'd need to do with the servers, I probably wouldn't need to do it. It's really hard to investigate problems without tools. Nobody is going to make a graph for how much cpu poorly configured docker/datadog are wasting rereading the same 1GB of json logs once or twice a minute, because nobody thought it would be meaningful, but watching top in one window, and running lsof at the right time to see what's being read, and whatever performance tools are hanging out to confirm.
    - AtlasBarfed 4y ago
      Ah the dream of easy to administer, perfectly adapted fine grained access permissions that can predict the future of exactly what an authorized user can run and needs to do. It never works because of the lack of precog, ticket walls, escalation over policy requiring reviews, and other bureaucracy. What they end up replacing ssh with (teleport or aws ssm are the two I've been forced to use) are slow, spotty, crash frequently, and who knows what vulnerabilities they have. If all these companies trying to get rid of sshd want to slap their own daemon on to replace it, why not keep sshd and simply have a deamon that manages the keys and not throw out the entire tool chain? The most fun thing with teleport and aws-ssm: to use it you had to bring up a web page to authenticate. There goes any hope of automation at scale. Because in a world where you're supposed to treat servers like cattle, let's impose (and I mean impose) a regime that forces you to access them one at a time manually, especially in critical situations.
  - imiric 4y ago
    > Distributing SSH keys across hundreds of machines is a nontrivial task. SSH certificates are a thing.
    - xena 4y ago
      Now you have two problems
wkat4242 4y ago
In the enterprise key management can become a bitch really quickly. Good luck updating 10.000 servers every time an admin leaves. For them ssh certificates are much better because you can simply revoke them, and new certs don't have to be added to each server. At home I still use keys though, but as an enterprise admin I see the issues. Even at home it's kinda annoying having to add a new yubikey to 20 servers.
- hobobaggins 4y ago
  Unless you use something like Userify. It's like my secret tool that no one knows about..
- janc_ 4y ago
  You could use AuthorizedKeysCommand or some other method to manage your keys in one central place.
  - wkat4242 4y ago
    You can, but you still need to set up a secure infrastructure to manage all the requests going back and forth. And most enterprises already have a completely functional and secured PKI, usually with the whole HSM deal and everything. It's plug and play and works with your existing infra.
- still_grokking 4y ago
  > In the enterprise key management can become a bitch really quickly. Good luck updating 10.000 servers every time an admin leaves. Can't "jump host" solve this? (Not an admin, so please excuse if the question is stupid).
  - xena 4y ago
    No
- account-5 4y ago
  You have 20 servers at home? What's you electrical bill like?
StreamBright 4y ago
It is not as much the enterprise security industry as it is better security for all. Problem with the current implementation with ssh keys is that there are non-trivial problems with it. For example how do you revoke a key? It is not possible in a central AAA service to revoke access for a user like it is possible for other kind of auth systems. Ssh and ssh keys were designed in an era where security was not really the primary concern. I think Facebook DevOps team had some detailed article how they manage ssh access to fb production with keys.
- CameronNemo 4y ago
  There is so many things wrong with your comment it is not even worth explaining.

mid-kid 4y ago

Using key-based auth without encrypting the key with a password sounds like a bad idea, as then any program running on the host can trivially gain root privileges.

remram 4y ago
Any program running as your user on your personal machine can trivially gain root privileges, by dropping a program called "sudo" in your personal PATH, putting a "sudo" command in your .bashrc, man-in-the-middle a shell (how do you know that last command actually completed?), or hijacking any of the graphical programs that trivially ask you for your UNIX password to do anything (Discord/Slack/... updater, Steam, ...)
- pxc 4y ago
  When do any of those programs ask you for your password? I've never had any of them ask for my Unix password, ever. Is that just a macOS thing with self-updaters?
  - remram 4y ago
    I'm using Ubuntu/KDE/Plasma. "Discover" is the GUI app that prompts you to install system updates, and will ask for your password when you do (to run apt/dpkg as root). Discord doesn't directly ask for my password, it downloads a .deb from somewhere and opens it, and I get prompted for my password then. Not much different IMHO.
    - still_grokking 4y ago
      I'm using Debian(Testing)/KDE/Plasma. (What was the point here?) I don't have any "Discover" installed as it's not needed for anything. There's aptitude… Regarding Discord: Discord is a virus. I try to avoid it. (And since you can't register without getting naked and showing the virus your telephone number it's not difficult to avoid ;-)).
      - 4y ago