@Axoren When the answer involves setting the sticky bit for directories, I find it easier to see when the permissions are in octal.

What situation did you find yourself in that you wanted to add tomcat to the sudoers file?

We didn't want to add tomcat to the sudoer's file. We wanted to add a user that was already in the sudoer's group to the tomcat group.

After running the one liner they had before, it replaced ALL GROUPS with just 'tomcat'

Our code base was only writable by users in a certain dev usergroup

And we no longer had that

And we also didn't have sudo to fix it

And root didn't have a password (only the SysAdmin had a key)

Recommendation: It's extra work, but just give every dev their own account even if you're a low-budget research group. That way, you don't risk losing full access to the machine when one person runs an erroneous one-liner

For my time, it's ssh key per user, a bastion host, and simple readme with ssh config instructions for using the jump host.

Oh, nvm. They could run usermod because they were in a sudoers group and they used it to remove themselves from the sudoers group.

I accidentally sent SIGSTOP to the sshd process for my user. That was embarrassing... had to ask, "hey, could you kill -18 31685?"

Most of the SSH landscape is utter garbage. I recommend you never use ssh-agent because the manual's instructions leave you with 100s upon 100s of zombie processes all floating around waiting for you to kill them manually because the script they give you doesn't reuse your original agents

SSH and the keygen utilities and SCP are the only things I really use from it.

You can always specify the key to use at the command line if that's more your speed. I don't mind ssh-agent, but now I'm poking around to see if there are a bunch of orphan ssh-agents.

I must have mine configured nicely. I don't see a proliferation of defunct processes or orphans still running.

The best was I saw to configure it was to have it ship your current agent from your laptop or other device to the server using -A. That way, it doesn't even try to populate a new one just for your time on that other server. The proliferation comes from initiating ssh-agent on an entry-point host and then doing so from multiple laptop terminals.

And those only shut off when you tell them to, so they stay on the server waiting for your next session to use them

I haven't noticed multiple ssh-agents per user on my remotes. For multiple logins from the same laptop i use a control master. Saves me the trouble of having to login again.