Is it OK to set up passwordless `sudo` on a cloud server?

I love the idea of accessing servers via keys, so that I don't have to type in my password every time I ssh into a box, I even lock my user's (not root) password (passwd -l username) so it's impossible to log in without a key.

But all of this breaks if I'm required to enter password for sudo commands. So I'm tempted to set up passwordless sudo to make things in line with passwordless login.

However, I keep having a gut feeling that it may backfire at me in some unexpected way, it just seems somehow insecure. Are there any caveats with such set up? Would you recommend/not recommend doing this for a user account on a server?

Clarifications

1. I'm talking about the use of sudo in an interactive user session here, not for services or administrative scripts
2. I'm talking about using a cloud server (so I have no physical local access to a machine and can only log in remotely)
3. I know that sudo has a timeout during which I don't have to re-enter my password. But my concert isn't really about wasting the extra time to physically type in a password. My idea though was to not have to deal with a password at all, because I assume that:
   • If I have to memorize it at all, it's very likely too short to be secure or reused
   • If I generate a long and unique password for my remote account, I'll have to store it somewhere (a local password manager program or a cloud service) and fetch it every time I want to use sudo. I hoped I could avoid that.

So with this question I wanted to better understand the risks, caveats and tradeoffs of one possible configuration over the others.

Follow up 1

All answers say that passwordless sudo is insecure as it allows "easy" escalation of privileges if my personal user account gets compromised. I understand that. But on the other hand, if I use a password, we incur all the classic risks with passwords (too short or common string, repeated across different services, etc.). But I guess that if I disable password authentication in /etc/ssh/sshd_config so that you still have to have a key to log in, I can use a simpler password just for sudo that's easier to type in? Is that a valid strategy?

Follow up 2

If I also have a key to log in as root via ssh, if somebody gets access to my computer and steal my keys (they're still protected by OS' keyring password though!), they might as well get a direct access to the root account, bypassing the sudo path. What should be the policy for accessing the root account then?

Solution 1:

I love the idea of accessing servers via keys, so that I don't have to type in my password every time I ssh into a box, I even lock my user's (not root) password (passwd -l username) so it's impossible to log in without a key...Would you recommend/not recommend doing this for a user account on a server?

You're going about disabling password-based logins the wrong way. Instead of locking a user's account, set PasswordAuthentication no in your /etc/ssh/sshd_config.

With that set, password authentication is disabled for ssh, but you can still use a password for sudo.

The only time I recommend setting NOPASSWD in sudo is for service accounts, where processes need to be able to run commands via sudo programmatically. In those circumstances, make sure that you explicitly whitelist only the specific commands that account needs to run. For interactive accounts, you should always leave passwords enabled.

Responses to your follow-up questions:

But I guess that if I disable password authentication in /etc/ssh/sshd_config so that you still have to have a key to log in, I can use a simpler password just for sudo that's easier to type in? Is that a valid strategy?

Yes, that's correct. I still recommend using relatively strong local account passwords, but not ridiculously-strong. ~8 characters, randomly generated is sufficient.

If I also have a key to log in as root via ssh, if somebody gets access to my computer and steal my keys (they're still protected by OS' keyring password though!), they might as well get a direct access to the root account, bypassing the sudo path.

Root access via ssh should be disabled. Period. Set PermitRootLogin no in your sshd_config.

What should be the policy for accessing the root account then?

You should always have a means of obtaining out-of-band access to the console of your server. Several VPS vendors do provide this, as do vendors of dedicated hardware. If your provider doesn't grant real console access (say, EC2 for instance), you can typically still restore access using a process like what I outline in this answer.

Solution 2:

I generally restrict use of NOPASSWORD to commands that are run by an automated process. It is preferable to have a service account for these commands, and restrict the use of sudo to the required commands.

Allowing NOPASSWORD for general commands, allows anyone who gets access to your userid to run any commands. This could result from a compromise of your credentials, but could be as simple as someone sitting at your desk when you step away for a second.

I find I don't have to enter my password that often. Once you enter your password, you can run several commands if you don't wait too long between them. The timeout is configurable.

Solution 3:

You can have the best of both worlds: SSH authentication for both login and for sudo. If you integrate the pam_ssh_agent_auth module you can use SSH keys to authenticate without giving a password when you sudo.

I've been using this in production for more than five years.

To configure it, install the PAM module, and then add a line to /etc/pam.d/sudo or your system's equivalent:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

If you do this, be sure to protect your keys on your computer with a passphrase. That way, someone would have to break into your computer and steal the keys to get in. They could do that by pulling them from memory while they were unlocked if they have access to your account, by cracking your passphrase, or stealing your passphrase through a keylogger or shoulder surfing it while you type it in (look behind you!).

You can use the same SSH key as you do to login, or you could set up a separate key that you only add to your agent when you sudo. So if you want to be extra careful, you could maintain a separate authorized_keys file that has a separate SSH key that you only add to your agent when you need to sudo:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

Solution 4:

I would only use this in two circumstances:

• When it is absolutely required for an automated script that is running as a specific user
• For specific admin tasks (read only admin tasks, not those that take action to alter the system) and then only for specific users of course

By default most sudo configurations will not ask you again for a while in the same session (if you open a new shell that doesn't have any effect). You can control this behaviour to an extent with the timestamp_timeout setting.

Password-less sudo is not nearly as dangerous as passphrase-less ssh keys, as a remote attacker needs your credentials to get in in the first place, but if they have got in by somehow compromising your private key (or if they are physically local to you and you've left yourself logged in and unlocked while away from the machine) then the password request is a valuable extra defence between them and privileged access.

Regarding follow-up 2:

If I also have a key to log in as root via ssh

This is best avoided too, for exactly the reason you describe. If a remote connection must have privileged access have it login via a service account and give that just enough control to do its job via sudo. This is more faf to configure of course so many don't bother (which works in your favour if you do, as there is plenty of lower hanging fruit than you for attackers to spend there time on!), so it comes down to the age old compromise between security and convenience (pro tip: pick security!).