How to connect to a distant server using SSH
This post is free for all to read thanks to the investment Mindsers Courses members have made in our independent publication. If this work is meaningful to you, I invite you to join our courses 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.
Installing SSH
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.
For those who have a Windows client machine, you can install SSH clients like PuTTY or OpenSSH.
Configuration
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 "your_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.
PubkeyAuthentication
is indicated as yes
in the file /etc/ssh/sshd_config
.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
Change Port
to any numeric value (retain it) above 1024, PermitRootLogin
and PasswordAuthentication
to 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 user@server.com -p 2923 # to log in
ssh user@server.com # doesn't work
ssh root@server.com -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 ~/.ssh/config
.
# 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 domain.org
and sub.domain.com
hosts.
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 User
and 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:
ssh gitserver
You can compare both versions of the connection command, the last is obviously simpler.
Join 250+ 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!