Create the user
On Ubuntu and Debian, adduser asks for a password and some optional details, which you can skip with Enter:
sudo adduser deploy
sudo usermod -aG sudo deployThe -a matters: without it, -G replaces the user's other groups. A minimal Debian may not have sudo at all, so run apt install sudo as root first.
On RHEL, Rocky, AlmaLinux and Fedora the admin group is wheel:
sudo useradd -m -G wheel deploy
sudo passwd deployCheck the result:
id deploy
sudo -l -U deployInstall the SSH key
Run this on the server, with the user's public key in place of the example. It sets the owner and modes in one step:
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
echo 'ssh-ed25519 AAAA... you@laptop' | sudo install -m 600 -o deploy -g deploy /dev/stdin /home/deploy/.ssh/authorized_keysThis writes a new file, replacing any existing one, so use it only for a new account. If the account has a password and password login is on, you can instead do this from your own machine, which appends the key:
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@serverOn systems with SELinux enforcing, fix the labels too:
sudo restorecon -R /home/deploy/.sshThe permissions that matter
| Path | Owner | Mode |
|---|---|---|
/home/deploy | deploy | not writable by others, for example 750 |
/home/deploy/.ssh | deploy | 700 |
/home/deploy/.ssh/authorized_keys | deploy | 600 |
The classic mistake is creating these files as root and forgetting the owner. In our test, a file owned by root with mode 600 gave this, since the user cannot read it:
deploy@server: Permission denied (publickey,password).Check with this, and see Permission denied (publickey) if the owners and modes are right but it still fails:
sudo stat -c '%a %U %n' /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keysDebian and Ubuntu are more relaxed about group-writable folders when the group is the user's private one: our login still worked with .ssh at 775. Do not count on it, since other systems refuse this. Stick to the table.
Test it before you close your session
Open a new terminal and leave the old one logged in:
ssh deploy@server
sudo whoamiThe second command should print root after asking for the password of deploy. Only then is it safe to disable root login or password login.
A user with a key and no password
For an account created from a script:
sudo adduser --disabled-password --comment "" deployOn older releases, such as Ubuntu 22.04, the option is --gecos "". Key login still worked in our test on Ubuntu 24.04, but sudo cannot ask for a password that does not exist:
sudo: a password is requiredEither set a password, or allow sudo without one for this user. Always create that file with visudo, which refuses a broken file:
sudo visudo -f /etc/sudoers.d/90-deploywith this line inside:
deploy ALL=(ALL) NOPASSWD:ALLUnderstand the cost: anyone who gets this key, or a shell as this user, immediately has root. Automation sometimes needs it, and a person logging in by hand rarely does. See using sudo over SSH safely.
Questions
How do I give an existing user sudo?
Run sudo usermod -aG sudo username on Debian and Ubuntu, or sudo usermod -aG wheel username on RHEL and Fedora. The user gets it at the next login.
Why is sudo asking for a password when I log in with a key?
They are separate. The key proves who you are to SSH. sudo asks for the account's own password, unless the sudoers file says otherwise.
Do I need to log out after adding the group?
Yes. Group membership is read at login, so a session opened before usermod does not have it.
Sources
- sshd(8), AUTHORIZED_KEYS and file permissions, OpenBSD manual
- sshd_config(5), StrictModes, OpenBSD manual