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.
- 1 Generate private and public keys
- 2 Copy identification to the server
- 3 More authorized machines
- 4 Some configurations for SSH server
- 5 Login screen
- 6 Troubleshooting
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.
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:
and write instead:
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:
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
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.
We can also, provide a personal message to users. We can do in two ways, with a static or dynamic text:
We can do it by editing in the remote server /etc/ssh/sshd_conf and adding, if we can’t find, the file:
Then, we edit this file ( /etc/issue.net) and add the text we want to show.
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.
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