After following this guide, you’ll get an identity file-based SSH authentication like AWS, HP cloud provides a way to log in. Commonly most of the cloud servers and dedicated servers are delivered with SSH login using the root user account. This is a security risk since any attacker can easily guess the username root
and run a dictionary-based attack. The attackers can log in using the root
account using different types of methods.
So, it is important to perform a few steps so that we can log in to a non-root user account belonging to the sudoers group using a certificate-based identification system. After a successful login, we can run the sudo su
command to gain the root privilege. Usually, we can always log in to the server from the web host’s API-based web terminal. Still, it is mandatory to make sure that we do not loss the root privilege of the server.
Create a non-root User and Disable SSH Login of the root User
SSH as root user and add a new user with the command:
---
1 | adduser example-name |
example-name
is an example. You can replace newuser
with any username you wish. It can be harry, joe, krishna etc. The adduser
command creates a new user, plus a group and home directory for that user.
You may get an error message that you have insufficient privileges. (This typically only happens for non-root users.) The system will add the new user; then prompt you to enter a password. Enter a secure password, then retype it to confirm. You can SSH to the server with this username and password but you’ll not gain the root privilege. For that reason, we have to add the new user to the sudoers group:
1 | usermod -aG sudo example-name |
Now, open a new terminal window and try to SSH with this username. After login, type sudo su
and check whether you can run commands just like the root user. If you can, then move to the next step. Open the SSH configuration file while logged in as this user. Do not keep any SSH session open from the root user account:
1 | nano /etc/ssh/sshd_config |
Find the line PermitRootLogin
and set it to no:
1 2 3 | ... PermitRootLogin no ... |
restart the service:
1 | service sshd restart |
Now, you’ll unable to SSH as the root user. This is secure but we will make the system more secure.
Setup SSH Login with pem file Without Password
Login as this newly created user and run sudo su
to gain root privilege. Run these commands:
1 2 3 | mkdir -p ~/.ssh/pem cd ~/.ssh/pem ssh-keygen -b 2048 -f identity -t rsa |
Hit the Enter key to leave passphare empty. It will generate 2 files in pem dir (identity and identity.pub). Copy public key contents to authorized_keys:
1 | cat identity.pub >> ~/.ssh/authorized_keys |
Run a cat
command on authorized_keys
to verify the content. Now run cat
on the private key:
1 | cat ~/.ssh/pem/identity |
This is the file you’ll use to SSH to the server. Highlight the content using your mouse and copy it. Paste it on your local computer’s new text file (save it as name.pem
, the name
can be anything you want). Save a copy on your GitHub private gist, Dropbox Cloud etc as a backup. Set permission for pem on your local copy:
1 | sudo chmod 600 name.pem |
First test whether you can SSH with this key to log in:
1 | ssh -i name.pem example-name@server-ip |
If you can, then disable the password-based authentication:
1 | nano /etc/ssh/sshd_config |
Update PasswordAuthentication from “yes” to “no” as below:
1 2 3 4 | ... # Change to no to disable tunnelled clear text passwords PasswordAuthentication no ... |
Restart SSH server:
1 | sudo service ssh restart |
This will make your server first require the PEM file to log in as your newly created user-name, then you need to type the password after typing sudo su
to gain the root privilege. This is a quite secure system for SSH login and is highly recommended by security experts.
In case you need to demonstrate SSH commands, never reveal the username to an untrusted audience. Run sudo su
to gain the root privilege and demonstrate. You can always run the whoami
command to check what is your username. Later, you can run the last
command to quickly check the SSH login history.
If you run this command:
1 | grep "Failed password" /var/log/auth.log |
You’ll realize the bulk of brute force attack every day takes place by automated systems. People who write these brute force scripts are quite clever, check the tried user names:
