34

SSH with public-private key authentication comes enabled by default with most Linux distributions. This is great because when I create accounts for remote users I don't have to email them sensitive info(passwords).

However, this process becomes useless when these users need to run sudo -- the server is still asking for their passwords. That means I still need to generate passwords for these users and figure out how to securely get it to them.

I know about sudoers file and NOPASSWORD parameter. However, I feel uneasy enabling it. I would still want some sort of authentication before users can run sudo commands.

While doing some research on this topic I found pam_ssh_agent_auth project, which from my understanding enables the same private/public key authentication as used for ssh connections but for sudo command.

It seems like with this module in place we can have completely passwordless accounts.

Why is this module or similar process is not part of standard Linux distro configs? Is there some security caveat I'm missing why this is not more widely adopted? Why passworded sudo is considered to be more secure than public/private key sudo?

  • Can't they just run passwd on their first login to set their password ? – user42178 Mar 25 '15 at 11:20
  • @AndréDaniel passwd requires entering user's "current" password – Mxx Mar 27 '15 at 19:37
  • There is public/private key alternative to sudo -- it's ssh :) -- see my answer for details. – galaxy Jul 18 '15 at 12:14
  • Just adding feedback for this solution. It doesn't quite work for permission modifying commands like chmod and chown (there are legitimate workflows and use cases where this is needed), as those implicitly require root privileges - unless you grant r_service sudo rights!! In which case, why go through all that, when you can just enable sudo? Edit: This is reply to Galaxy's answer about not using sudo. – user90272 Oct 26 '15 at 18:22
15

I am trying a different approach that doesn't require creating and managing passwords: I set up key-based authentication with the user's public key, disabled password-based authenticon for ssh and set up the user accounts with an empty but expired password (passwd -de). That way users get prompted on their first login and can choose their own passwords.

I am feeling a bit uneasy about the empty password but as far as I can tell, it's fine as long as password authentication for ssh is disabled and there are no other services running that require authentication (IMAP or something). Any opinions on this?

  • That's a creative solution. – gowenfawr Mar 25 '15 at 11:30
  • I'd be afraid of the empty password. Couldn't another user on the same machine get into and change the password from su or something similar? – Michael Apr 19 '16 at 10:43
  • 5
    That's assuming SSH is the only way into the server right? (no local access, Apache/ftpd doesn't authenticate against local accounts, etc.) Also, what happens when someone does sudo -u <some_other_user_with_empty_password>...? – user193130 Apr 28 '16 at 14:57
6

In my opinion, sudo for server admins is a bit overkill. If people log in, and they have root access (through some mechanism), they usually do maintaining tasks, where they will use sudo for >90% of the time. The purpose of sudo is to give accounts that are logged in some separation between untrusted applications and admin-like tasks, and make users aware they are changing the system (and have to watch out). For desktops, both applies. For servers however, most tasks will already require sudo, so both points get weak. sudo has some advantages with its fine-grained control, but to rely on its logging capabilities, you would need to set up remote logging, as otherwise people with root access can falsify past logs.

Is there some security caveat I'm missing why this is not more widely adopted?

pam_ssh_agent_auth requires ssh-agent forwarding in order to work over ssh. Then however its a bit pointless to use it, as then every (non-cgrouped) process running under the user's account could use the agent to execute commands as root. This enables every such process to run sudo which is precisely what the NOPASSWORD parameter does.

My advice would be to have NOPASSWORD and be happy with it. It still gives people the feeling "now I change the system", but it doesn't have annoying passwords.

If you still wanted to have passwords, you could e-mail them in clear, but require them to be changed the first time they get used. An attacker would need both the email and the user's private key to be successful. If they already have access to the private key, they could do some nasty things to .bashrc and get access the next time the user gets sudo with a password that the attacker doesn't need to know.

  • sudo for servers is not an overkill when you must restart some service. And I can't hardcode specific command into sudoers due to issues beyond the scope of this question. Can you please elaborate on your 2nd paragraph? ssh-agent is running on the client's system, not server, and only when connected. – Mxx Nov 11 '14 at 15:43
  • From the man page: the ssh-agent listening to SSH_AUTH_SOCK can either be local, or forwarded. With 'local' the man page means 'running on the server'. – user10008 Nov 11 '14 at 18:38
  • I fail to see how using pam_ssh_agent_auth improves upon using sudo NOPASSWD either. If you you want to circumvent having to enter the sudo password repeatedly you could just extend the sudo timeout. – ofrommel Mar 25 '15 at 12:38
6

I suggest to avoid even installing sudo on your systems: it's an additional attack vector with usually no justification for having it. I wrote an article on the sudo (mis)usage if you are interested to learn more on the topic: http://dmitry.khlebnikov.net/2015/07/should-we-use-sudo-for-day-to-day.html

Re: the original question - if you need some privileged command to be executed by non-privileged users you may use the following trick:

  1. generate a passphrase-less SSH key
  2. prepend the public part with the following: from="127.0.0.1",command="your_desired_command_here",no-pty,no-port-forwarding,no-agent-forwarding (you can also restrict the SSH session further, see "man sshd"). Note that the key should be separated from this header by a space character.
  3. install that public key to privileged account's ~/.ssh/authorized_keys
  4. provide the user with the private key (or create a script that simply SSH in over the loopback interface to the privileged account using the private key)

For example, if the privileged account is r_service (created with useradd -om -u0 -g0 -d /root/service -s /bin/bash r_service) the call to that privileged command from a non-privileged account would be something like:

$ ssh -i ~/.ssh/privileged_command r_service@0

This way you will grant your users to execute that privileged command without compromising the security model.

  • 2
    very interesting article – Supersharp Jan 10 '17 at 11:29
1

SSH authentication and security privileges are two different things, hence no point of having it as a default feature. However, it opens one more vector for attack(there is a CVE) and from my point of view makes it easier for users to overuse it, which is bad.

On the topic of passwords, one way is to send a short-lived password to the user and require him/her to change it after initial login. Or allow them to "register" their account and only work with the hash. There is pros and cons in every approach, but a good place for inspiration is the commercial and free Shell account services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.