This page is part of the guide: Basic configuration of a Linux based dedicated server, vps or cloud server.

The first step is to secure SSH access, so we must remove password asking, we will log in with a private/public key pair. We must generate a new pair of keys for each computer we want to connect. This will  be more comfortable for us, and more secure, among other things, because this file is bigger than any normal key we have in this server.

Generate private and public keys

This must be done in our local computer.

Although SSH version 2 allows generation of several types of key (RSA, DSA and ECDSA), there isn’t a way to determine which one of these algorithms is better, there is a big discussion about that. Maybe we can determine between DSA and ECDSA, the second is better, because keys are smallers with equivalent security level, and it is a bit faster when generating and validating. But key lenghts and security of DSA and RSA are equivalent, they are different algorithms, but for SSH, DSA keys must be only 1024bit lenght, while not for RSA keys.

Though SSH documentation says 2048bit RSA key is enough, we will create 4096bit keys:

$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in wich to save the key (/home/cloud/.ssh/id_rsa):
Enter passphase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/cloud/.ssh/id_rsa.
Your public key has been saved in /home/cloud/.ssh/id_rsa.pub
The fingerprint is …

In this step, we are asked for a password, if we want more security, in this case, we can give no pass, we will need the key file to access a server.

When we are finished, we will find two new files in $HOME/.ssh/, id_rsa and id_rsa.pub (in the generation process we are asked for the name of the file).

Copy identification to the server

Now we must transfer the file to the server, if we have ssh access by password, we can do:

$ ssh-copy-id user@server

But if our public key is not named id_rsa.pub, we can type:

$ ssh-copy-id -I identity_file user@server

If instead we don’t have ssh access at this moment (maybe in the future we won’t allow this), or we don’t have ssh-copy-id command, we must append our public key at the end of the file $HOME/.ssh/authorized_keys, in other words, we can copy the file id_rsa.pub (or the name of our public key) into /home/cloud/tmp/, then:

cloud $ cat ~/tmp/id_rsa.pub >> ~/.ssh/authorized_keys

So, every authorized key for this remote user will be attached into the same file.

More authorized machines

We can repeat this process freely if we want to access our server from another machines. But we must be careful not to delete the file authorized_keys, so it is recommendable to backup periodically this file.

Some configurations for SSH server

These changes must be done to /etc/ssh/sshd_config file of our remote server.

Disable password authentication

Maybe we are allowing both types of authentication, so we must disable password authentication, we must update the line:

PasswordAuthentication yes

and write instead:

PasswordAuthentication no

Maybe we can’t find the first line, or maybe it is commented (with # before), so we add the second line.

Make sure we cant log in as root

For that, we must change:

PermitRootLogin yes

to

PermitRootLogin no

List users allowed by our server

Maybe we don’t want to allow all users of the system log in through ssh, so we can define two configurations:

AllowUsers peter andrew jasper

or

DenyUsers alex guest

The first one allows users like pedro, andrew and jasper to log into the system, and only these users, but if it’s easier to describe the access to our system by saying who cannot enter, we can use the second case.

Login screen

We can also, provide a personal message to users. We can do in two ways, with a static or dynamic text:

Static text

We can do it by editing in the remote server /etc/ssh/sshd_conf and adding, if we can’t find, the file:

Banner /etc/issue.net

Then, we edit this file ( /etc/issue.net) and add the text we want to show.

Dynamic text

We can do it taking advantage of the Message Of The Day (motd), in most modern Linux distributions we can find in /etc the folder update-motd.d where we can add bash scripts which can provide a personal message to the user who have just logged in, locally or remotelly.

Troubleshooting

If permissions can’t be read when we are connecting to a remote server, we must make sure the permission for the $HOME/.ssh diretory is 0700, i.e. read, write and execution just for the owner. To do so:

$ chmod 0700 ~/.ssh