Secure Shell (SSH) is a protocol through which you can access your Cloud Server and run shell commands. As the name suggests, SSH is encrypted with SSL, which makes it difficult -- but not impossible -- for these communications to be intercepted and read. What follows is a brief guide on connecting for the first time and locking down the SSH service.

Note: Many of the commands in this article must be run on your local machine. The default commands listed are for the Linux command line or MacOS X Terminal.  To make SSH connections from Windows you can use a free program called PuTTY, and to generate keys you can use a related program, PuTTYGen.  To use SCP on Windows you can use a program like WinSCP.

Log in

As soon as you have your IP address and password for your Cloud Server, login via SSH:

ssh root@123.45.67.890

If you rebuilt your Cloud Server, you may get a message informing you that the "remote host identification has changed".

When you log into a Cloud Server via SSH, one of the security features is matching the remote host with known keys. When you rebuild a Cloud Server, the remote host key changes. As such, your computer thinks there is something dodgy going on.

If you want to be absolutely sure of your security, you can use the web console in the control panel to verify your server's new key.  If you want to skip that step, then all you need to do is delete the record of the old ssh host key.

On your local computer, edit the SSH known_hosts file and remove any entries that point to your Cloud Server IP address.

nano ~/.ssh/known_hosts

If you are not using Linux or a Mac on your local computer, the location of the known_hosts file will differ. Please refer to your own OS for details of where this file is kept.

SSH keygen

One effective way of securing SSH access to your cloud server is to use a public/private key. This means that a 'public' key is placed on the server and the 'private' key is on our local workstation. This makes it impossible for someone to log in using just a password - they must have the private key.

The first step is to create a folder to hold your keys. On your LOCAL workstation:

mkdir ~/.ssh

That's assuming you use Linux or a Mac and the folder does not exist. I will do a separate article for key generation using Putty for Windows users.

To create the ssh keys, on your local workstation enter:

ssh-keygen -t rsa

If you do not want a passphrase then just press enter when prompted.

That created two files in the .ssh directory: id_rsa and id_rsa.pub. The pub file holds the public key. This is the file that is placed on the Cloud Server.

The other file is your private key. Never show, give away or keep this file on a public computer.

Make a user

If you haven't already, create a new user that you'll use to make ssh connections to your server:

/usr/sbin/adduser demo

The username can be anything you like, just replace "demo" above.  You'll probably also want to add that user to the list of users that can use sudo, by running:

visudo

And then adding a line to the end of the file:

demo   ALL=(ALL) ALL

SSH copy

Now we need to get the public key file onto the Cloud Server.

We'll use the 'scp' (secure copy) command for this as it is an easy and secure means of transferring files.

Still on your local workstation enter this command:

scp ~/.ssh/id_rsa.pub demo@123.45.67.890:/home/demo/

When prompted, enter the demo user password.

Change the IP address to your cloud server and the location to your admin user's home directory (remember the admin user in this example is called demo).

SSH Permissions

OK, so now we've created the public/private keys and we've copied the public key onto the Cloud Server.

Now we need to sort out a few permissions for the ssh key.

On your Cloud Server, create a directory called .ssh in the 'demo' user's home folder and move the pub key into it.

mkdir /home/demo/.ssh
mv /home/demo/id_rsa.pub /home/demo/.ssh/authorized_keys

Now we can set the correct permissions on the key:

chown -R demo:demo /home/demo/.ssh
chmod 700 /home/demo/.ssh
chmod 600 /home/demo/.ssh/authorized_keys

Again, change the 'demo' user and group to your admin user and group.

It may seem a long set of steps but once you have done it once you can see the order of things: create the key on your local workstation, copy the public key to the Cloud Server and set the correct permissions for the key.

SSH config

Next we'll change the default SSH configuration to make it more secure:

nano /etc/ssh/sshd_config

The main things to change, check, and add are:

Port 30000                           <--- change to a port of your choosing
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers demo

The settings should be fairly self explanatory but the main thing is to move it from the default port of 22 to one of your choosing, turn off root logins and define which users can log in.

NOTE: the port number can readily be any integer between 1025 and 65536 (inclusive), but should be noted for reference later when any additional listening processes are setup, as it will be important to avoid conflicts.

PasswordAuthentication has been turned off as we setup the public/private key earlier. Do note that if you intend to access your cloud server from different computers you may want leave PasswordAuthentication set to yes. Only use the private key if the local computer is secure (i.e. don't put the private key on a work computer).

Changing iptables

If you have a firewall active and you changed the port of the ssh server, you'll need to make sure your firewall won't block that new port.

If you already have a rule for ssh, it's probably on port 22.  The iptables instruction for that port looks like:

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Change the "22" to the port you'll be using, for example, to "30000".  For more details you can read our introduction to iptables, but the basics of setting the firewall rule for some of the more popular distributions are:

Ubuntu and Debian

On more recent versions of Ubuntu and Debian you can run:

iptables -A INPUT -p tcp -m tcp --dport 30000 -j ACCEPT
iptables-save

CentOS, Fedora, and RHEL

For Red Hat-based distributions like CentOS, Fedora, and RHEL, run:

iptables -A INPUT -p tcp -m tcp --dport 30000 -j ACCEPT
service iptables save

Restarting sshd

Once you've made all your changes be sure to restart sshd so the new settings will take effect.  To be safe, don't log out of your original ssh session until you've tested the new settings with another connection.

Ubuntu and Debian

To restart the ssh server on Ubuntu or Debian, run:

service ssh restart

CentOS, Fedora, and RHEL

To restart the ssh server on CentOS, Fedora, or RHEL, run:

service sshd restart

Connecting after the changes

If you're using an ssh client like PuTTY, be sure and edit the connection profile to switch the port from "22" to whatever you decided to use instead.

If you're connecting from the command line you can specify the port ssh will use with the "-p" option:

ssh -p 30000 demo@123.45.67.89

If you made the changes suggested earlier, then you won't be able to ssh in as root - just as the user you specified in the config, like "demo".

Troubleshooting

If you can't make a new connection after restarting the ssh server then you may want to go back over the steps listed here, check your changes, and then restart the ssh server when you're done and try again.

If you get a "connection timeout" error, then either you need to add your ssh port to iptables, or you might be specifying the wrong IP address when you're connecting.

If you get a "connection refused" error, then you are probably trying to ssh to the wrong port.  If you changed your ssh server to listen to a port other than 22, use the "-p" option with ssh to specify the port.

If you're getting a rejected login then it could be an issue with your key.  Try changing the sshd config to allow password connections (set "PasswordAuthentication" to "yes"), restart the ssh server, then try again.  If you can get in this time, then the issue is with the key - make sure it's in the right place on the server.