DB-유

Creating a sudo User and Disabling Root SSH Login

· linux, ssh, security

Every fresh VPS I get handed comes the same way: a single root account, a password in an email, and port 22 open to the world. Within a few hours the auth log fills up with password guesses against root. The first thing I do on any new CentOS 7 or Ubuntu 16.04 box is create a normal user with sudo rights, move my SSH key over, and shut the door on direct root logins.

You need root access, an SSH key pair on your workstation (ssh-keygen -t rsa -b 4096 if you don't have one), and a second terminal window. Keep the root session open until the new user is proven. I once skipped that and spent an evening in a provider's rescue console.

Create the user

On CentOS 7, the wheel group is what /etc/sudoers grants sudo to:

adduser deploy
passwd deploy
usermod -aG wheel deploy

On Ubuntu 16.04, the equivalent group is sudo:

adduser deploy
usermod -aG sudo deploy

Ubuntu's adduser is interactive and asks for the password and some optional fields; just press Enter through the ones you do not care about.

Confirm the group membership took effect:

id deploy

You should see wheel or sudo in the groups list. If you edit /etc/sudoers for any reason, always do it with visudo, which checks the syntax before saving. A broken sudoers file locks everyone out of sudo at once.

Install your SSH key for the new user

The cleanest way is from your workstation, if ssh-copy-id is available:

ssh-copy-id deploy@203.0.113.10

If you are already logged in as root and want to do it server-side, copy root's authorized key into the new home directory and fix ownership and permissions. SSH is strict about these:

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

On CentOS 7 with SELinux enforcing, also restore the context so sshd is allowed to read the file:

restorecon -Rv /home/deploy/.ssh

Test the new login before changing anything else

Open a second terminal and log in as the new user:

ssh deploy@203.0.113.10
sudo -i

You should get a root shell after typing the user's password. Do not proceed until this works. The root session in the first window is your safety net.

Now lock the door

Edit /etc/ssh/sshd_config:

vi /etc/ssh/sshd_config

Set or change these lines (uncomment them if they start with #):

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes

PermitRootLogin also accepts prohibit-password (older versions call it without-password), which allows root in with a key but not a password. I prefer a flat no; there is nothing root can do over SSH that sudo -i cannot.

Check the config for syntax errors before reloading:

sshd -t

No output means it is fine. Then reload the daemon. On CentOS 7:

systemctl reload sshd

On Ubuntu 16.04 the unit is called ssh:

systemctl reload ssh

A reload does not drop existing sessions, so your root window stays open even though new root logins are now refused.

Did it work?

From your workstation, try to log in as root. It should fail immediately:

ssh root@203.0.113.10

Expected result: Permission denied (publickey). Then confirm the normal user still works and can sudo:

ssh deploy@203.0.113.10 'sudo -n true && echo sudo ok'

That will prompt for a password (unless you set NOPASSWD), which is fine. Also watch the auth log for a minute to see the difference. On CentOS 7 it is /var/log/secure, on Ubuntu /var/log/auth.log.

Things that bit me

  • Permission denied (publickey) for the new user: nearly always permissions. ~/.ssh must be 700, authorized_keys must be 600, and both must be owned by the user. Run sshd in debug on a second port (/usr/sbin/sshd -d -p 2222) and connect with ssh -p 2222 to see exactly which check fails.
  • deploy is not in the sudoers file. This incident will be reported.: the group change did not apply. usermod -aG only affects new sessions, so log out and back in, and double-check with id.
  • On CentOS 7, %wheel ALL=(ALL) ALL must be uncommented in /etc/sudoers. Some minimal images ship it commented out. Fix it with visudo.
  • Locked out completely: use your provider's console or rescue mode, mount the disk and revert PermitRootLogin in sshd_config. This is exactly why the test login comes first.

None of this replaces a firewall or fail2ban. But the auth log gets a lot quieter, and every privileged action ends up tied to a named user.