Remote Virtual Private Server (VPS) Management

In this article we will be covering the basics of how to remotely manage a Linux based virtual private server. Remote control of a VPS through Linux is done through its console. If you're using Windows, however, you'll need to get a utility that allows you to connect to your Linux server over SSH, such as Putty. For Mac users, "SSH-client" is a built-in app that functions similarly. 

Using utilities like scprsyncsftp we can control the server as well as send and recieve files over an encrypted connection. As long as your server is properly configured to use SSH, it will be very secure from any possible intrusion. To that end, there's a couple of guidelines you should follow to ensure a secure configuration of your SSH-server; a) keep access credentials as private as possible, limiting them to only the individuals actively using the server and b) use access keys instead of password, since passwords are easier to create and easier to brute force.

We're going to set up SSH with a new server. For our example, we're going to pretend the server address is 10.0.0.9 and make up something for the root password.

tom@localhost ~ $ ssh root@10.0.0.9
The authenticity of host '10.0.0.9 (10.0.0.9)' can't be established.
ECDSA key fingerprint is SHA256:4wZrE6FkrR4W6wqLapM3+Xb3w0Rlv94B4kbaMqhdHgg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.9' (ECDSA) to the list of known hosts.
root@10.0.0.9's password: reoMeiMeiPh3eeF
[root@vps ~]#

Because this is the first time trying to establish a connection, SSH asks whether we want to add this server to the list of trusted connections (this list is located at ~/.ssh/known_hosts). If your redout looks like this, you've successfully connected to the server.

First thing we want to do with our new server is change the root password.

[root@vps ~]# passwd root
Changing password for user root.
New password: 
(your password, no brackets)
Retype new password: (your password, no brackets)
passwd: all authentication tokens updated successfully.

Now that that's done, we're going to create a local user. We'll just call the user Tom, for our example. Creating a local user is there for security purposes, since it's not a good idea to keep to only be using your root credentials. 

[root@vps ~]# useradd tom
[root@vps ~]# passwd tom
Changing password for user tom.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Now we'll need to copy the public key on your local computer to the remote server

tom@localhost ~ $ ssh-copy-id tom@10.0.0.9
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
tom@10.0.0.9's password:
Number of key(s) added: 1

This will now allow you to connect to your remote server, using the local user credentials, without a password:

tom@localhost ~ $ ssh tom@10.0.0.9
[tom@vps ~]$

Now, we'll just go back and generate keys on the server, and we have to go back to our root user to do it.

[tom@vps ~]$ su root
[root@vps ~]# ssh-keygen -A
ssh-keygen: generating new host keys: RSA1 DSA

That's all there is to that. Now, let's walk through basic server setup. We'll get through the commands first, and then break down what we did. So let's get to it.

[root@vps ~]# vim /etc/ssh/sshd_config
# Set default 22 port and second version of protocol
Port 22
Protocol 2

# Path to hostkeys
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

# Disable root login, password login
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no

# Path to authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

# We no need Xorg on server
X11Forwarding no

# Disable banner
Banner none

# Allow to login only user tom and group family
AllowUsers tom@*
AllowGroups family@*

# You can allow to login by root from trusted IPs
# Match host 192.168.0.10, 10.0.0.20
#   PermitRootLogin yes

After getting all that in, we need to restart the SSH service.

[root@vps ~]# systemctl restart sshd

So what we've done here is allow the SSH service on the server to work through the standard port 22, while only using version 2 of the protocol, since version 1 is outdated at this point and less secure. We've also restricted access to the server for root user, restricted access using passwords, turned off banner dispay and forwarding X11. Meanwhile, we're allowing access to the server for our user "tom" and anyone in the group he's in "family". 

It's worth noting that a lot of intrusions happen from bots trying to brute force your passwords. Switching your SSH port will repel the vast majority of them. However, some bots are written to check for this and can tell what port your SSH server is using. You can use fail2ban to fight off these kinds of bugs. Fail2ban scans SSH connections and will block any connection that fails to provide the correct password or SSH key 

 

On CentOS 7, fail2ban installs like this 

[root@vps ~]# yum install epel-release -y && yum install fail2ban -y

Once that's done, let's make a fail2ban config file.

[root@vps ~]# vim /etc/fail2ban/jail.local
[ssh-iptables]
enabled = true
filter = sshd

# Block by iptables
action = iptables[name=SSH, port=ssh, protocol=tcp]

# Sendmail settings
sendmail-whois[name=SSH, dest=admin@domain.com, sender=fail2ban@example.com, sendername="Fail2Ban"]

# Max 5 retries to login
maxretry = 5

# Ban for 24 hours
bantime = 86400

Now let's run the service to create an f2b-SSH chain in iptables:

[root@vps ~]# systemctl start fail2ban
[root@vps ~]# iptables -L f2b-SSH
Chain f2b-SSH (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

You can also manually add and remove connections from this block list. If we just use a made up IP right now, banning and unbanning looks like this

[root@vps ~]# fail2ban-client set ssh-iptables banip 10.0.0.3
[root@vps ~]# fail2ban-client set ssh-iptables unbanip 10.0.0.3

Well, that about does it for this article. We set up a remote SSH connection for secure, passwordless, remote server control, and added an extra security layer with fail2ban.  

Of course, all of this is also possible through ServerSuit, where you can control your server with our super intuitive UI as well as install apps and plugins like fail2ban and more! First 30 days is always free so give it a shot.

Follow us on Facebook and Twitter for product updates and new articles!

Until next time!

March 05 2018

Add or review comments

Please leave your comment

Existing comments

Comments 1


Arif Sadiq
Great article described in a simple way. It is very useful for beginners.

Get notified about new publications and product updates.
Please note we do not share information to anyone.