Remove Root Password for Safer SSH Access

by

Almost every Linux install comes with a root user and even if you give it a secure password you are at risk because an attacker can throw passwords at it forever and potentially access your systems. I’ve got several boxes around that I want to reduce the risk for but maintain remote access.

On the Server (Debian)

First, create another account to use instead of root. Assuming you are logged in as root right now you create a new account for Steve Martin with a home directory and set a secure password for that user with:

> useradd -m stevemartin > passwd stevemartin

Now, make that user a sudoer so they’ll have access to run all the important things that need escalated privileges. Again assume you are root so you can use:

> usermod -aG sudo stevemartin

You can check all the groups that the user is a member of with:

> groups stevemartin

On the Client (macOS)

Create a new key and give it a unique filename and add a comment that describes what the key is for. When asked give it a password.

> ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_texashost -C "Texas Host Connection"

The easiest way to get the key onto the server is using the ssh-copy-id command. If it isn’t installed you should figure out how to do that. It’s outside the scope of this article. So use it to copy the key (adding the pub file extension).

> ssh-copy-id -i ~/.ssh/id_ed25519_texashost.pub stevemartin@57.145.0.1

Now test that the connection works using a normal ssh command using the key (without the pub file extension).

> ssh -i ~/.ssh/id_ed25519_texashost stevemartin@57.145.0.1

Once you know that the key works for the connection we can make it even easier to setup the connection. So lets setup the ssh config file

> vim ~/.ssh/config

Host texashost
HostName 57.145.0.1
User stevemartin
IdentityFile ~/.ssh/id_ed25519_texashost.pub
IdentitiesOnly yes

Now you can use the short host id to connect to the server without a bunch of hassle.

> ssh texashost

On the Server (Debian)

Now it’s time to get dangerous. Since you know you can connect as a non-root user and you can use a key instead of the password time to start closing down root access. A lot of tutorials tell you to keep a second session connected to the ssh server so you don’t accidentally lose access but I’ve never had issues. Using your normal login on the server to disable root login via ssh and disable login in with password via ssh.

> sudo vim /etc/ssh/sshd_config

…
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
…
# To disable tunneled clear text passwords, change to “no” here!
PasswordAuthentication no
#PermitEmptyPasswords no
…

That would normally be good enough on a real server to disable root logins and password authentication but the cloud-init setup creates a file that overrides the password setting so you gotta delete that file and disable the cloud init from ever

> sudo rm /etc/ssh/sshd_config.d/50-cloud-init.conf > sudo touch /etc/cloud/cloud-init.disabled > sudo systemctl restart ssh

Now confirm that the password authentication is set for no on ssh. You are probably better off starting a new terminal with a new ssh to confirm that everything is running fresh.

> sudo sshd -T | grep -iE 'passwordauthentication

On the Client (macOS)

You can confirm that root logins and password logins don’t work because you’ll quickly denied when you attempt to use:

> ssh root@57.145.0.1 > ssh -o PreferredAuthentications=test -o PubkeyAuthentication=no stevemartin@57.145.0.1