This post is free for all to read thanks to the investment Mindsers Club members have made in our independent publication. If this work is meaningful to you, I invite you to join the club today.
Using SSH to connect to its servers seems like a basic thing, but for many, SSH remains an obscure software/protocol. We will clarify all this, and we will take the opportunity to go a bit further.
What is SSH?
Here is the definition given by Wikipedia:
Secure Shell (SSH) is both a computer program and a secure communication protocol. [...] All TCP segments are authenticated and encrypted. It therefore becomes impossible to use a sniffer to see what the user is doing.
Simply put, SSH is a secure “Shell” that allows us to take control of our remote servers.
It also allows you to do a multitude of other things, but we won't see them here.
To be able to use SSH, you will have to install it on the server machine and on the client machines.
On most Unix machines (including Linux and Mac) SSH is a package installed by default. If however on your machine this is not the case, you can launch a command like:
sudo apt-get install ssh
Change the package manager and its syntax to that of your distribution.
Now that you have installed SSH, you will need to configure it.
By default, all users on the server can initiate a remote connection with SSH. That means we can already use our machine remotely. On the other hand, we wouldn't want some smart guy to be able to log in as root on our server.
To prevent this, we will start by creating a new user on the server.
# Serveur adduser userName
Answer the questions posed by the utility, and your new user will be created and usable by SSH.
# Serveur adduser userName sudo
We add our new user to the list of users who have the right to perform certain tasks normally dedicated to the superuser without being one.
Connection using keys
Many attacks using the SSH protocol use the “brute force” method. Because of this, password-based logins are less secure than key pair-based logins.
Let's give our user the ability to login by keys.
# Client ssh-keygen -t rsa -b 4096 -C "email@example.com"
This command creates an RSA encryption key of 4096 bytes.
ssh-keygen generates a public key and a private key. The private key should never leave your machine and should never be shared with anyone.
# Serveur mkdir ~/.ssh
The public key we just created must be transferred to the remote server and added to the list of keys authorized to connect with the new user.
# Client ssh-copy-id -i adresse/de/votre/clepublique.pub user@server
If you do a test now (
ssh user@server) SSH should not ask you for a password to initiate the connection.
If you are prompted for a password, it means something went wrong with the steps above. I advise you not to move on without having solved the problem.
PubkeyAuthenticationis indicated as
yesin the file
Small additional security tweaks
Now that our new user is ready, let's prevent
root from logging in and change a few things.
# Serveur vim /etc/ssh/sshd_config
Port to any numeric value (retain it) above 1024,
no. You should have :
Port 2923 PermitRootLogin no PasswordAuthentication no
Thus, hackers who try to connect to your server on port 22 will fail. They also won't be able to log in directly to
root and have all rights too easily.
The last line prevents password authentication. So, no more “brute force” attacks, attempts by clever little guys who think they have found your password. Anyone who wants to connect to your server must have their public key (or one of their keys) saved in your machine.
To sum up:
# Client ssh firstname.lastname@example.org -p 2923 # to log in ssh email@example.com # doesn't work ssh firstname.lastname@example.org -p 2923 # doesn't work
.ssh/config : simplify your life
Imagine that you have several servers to manage, that for each one you have a different pair of keys, a different user: it is easy to see the mess that can become. A solution exists, the file
# Client vim ~/.ssh/config
Host sous.domaine.com IdentityFile /home/user/.ssh/privatekey Host domaine.org IdentityFile /home/user/.ssh/privatekey2
Thanks to the
IdentityFile key, SSH now knows which private key to use for
Host sous.domaine.com IdentityFile /home/user/.ssh/privatekey Host nomPersonnalisable HostName github.com IdentityFile /home/user/.ssh/privatekey3 Host nomPersonnalisable2 HostName github.com IdentityFile /home/user/.ssh/privatekey2
If you have two accounts on GitHub (or two users on any server) and different key pairs for each account, you can add the
HostName key with the domain name value and change
Host to a customizable name. Thus, you can have two different SSH configurations for the same server.
Host gitserver HostName git.com User userName Port 2923 IdentityFile /home/user/.ssh/privatekey2
Two other interesting keys to know are the
Port keys. Their name couldn't be clearer, and the example speaks for itself.
It's a simple config that allows us to connect to our server by typing:
You can compare both versions of the connection command, the last is obviously simpler.
Join 200+ developers and get notified every month about new content on the blog.
No spam ever. Unsubscribe in a single click at any time.
If you have any questions or advices, please create a comment below! I'll be really glad to read you. Also if you like this post, don't forget to share it with your friends. It helps a lot!