Myujth

With sudo, you can either set it to ask for a password or not ask for a password.

Historically, everything was password-protected, which is the model that I am used to. However, encryption seems to be favoring public/private key authentication more and more nowadays.

This is evident in the fact that when I spin up a server on GCP, AWS, or DigitalOcean, I don't get a password. Instead I get a key that I use to log in.

Now, if I want to do sudo when I am logged in, it doesn't ask me for a password. This is obviously due to the fact that a password was never given to me, only a key was. And sudo doesn't ask for a password because of the following rule in /etc/sudoers.d/90-cloud-init-users:

ubuntu ALL=(ALL) NOPASSWD:ALL

This is fine for one user. But what happens if a server has 3-4 users, all of whom need sudo access, and all of whom are using keys to log in rather than a password. You want to make sure that one user can't do

sudo su - <someone else's username>
sudo <command>

Is the encouraged practice to not allow password authentication when connecting with sshd, but to give all the users a password that is used for sudo authentication? Or to use pam_ssh_agent_auth to allow sudo to authenticate with another set of private/public keys that have a passphrase? Or is there something else that should be done?

Password authentication for access to sudo doesn't restrict what commands can be run.

eg

myuser ALL=(ALL) NOPASSWD: ALL
youruser ALL=(ALL) ALL

lets both users run exactly the same commands, just you need to enter your password, and I don't.

Instead the idea is to only grant users the privileged commands they need, rather than "ALL" commands. So if user1 only needs to reboot the server you might give them

user1 ALL=(root) NOPASSWD: /usr/sbin/reboot

Now all they can do is reboot the server.

This follows the principle of least privilege; only give people the commands they need.

Further reading: https://www.sweharris.org/post/2018-08-26-minimal-sudo/