Q:

SSH key auth, but still need password for sudo?

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?

A:

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?

A:

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:

generate a passphrase-less SSH key
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.
install that public key to privileged account's ~/.ssh/authorized_keys
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.

A:

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.

