UNIX & GNU/Linux - SSH - Communication between client and server

In this tutorial we are going to see how two computers can communicate with each other through the SSH protocol.

Why do we need SSH keys and how to use them?

We will use one computer as Server and another one as Client.

First of all

  • Ubuntu 18.04.01 (LTS): https://www.ubuntu.com/
  • openssh-server: directly from Ubuntu (more details in the tutorial)
Before starting we need some useful tools that we are going to install on Ubuntu:
sudo apt install net-tools

We can now see our IP address with the following command:


Your IP is next the "inet" word, something like that:

inet netmask broadcast

So do the same with your both Linux distributions.

Let’s say that we have eventually the following configuration:

  • Ubuntu Server:
  • Ubuntu Client:

Then let's say that we have 1 user on each machine with the corresponding password like that:

  • Server's user login: loginServer
  • Server's password: pw1
  • Server's machine name: PC1
  • Client's user login: loginClient
  • Client's password: pw2
  • Client's machine name: PC2

Let's now try to talk from Client to Server:

ssh loginMaster@

You should have the following message:

ssh: connect to host port 22: Connection refused


ssh: connect to host port 22: Connection timeout

It's normal because our Server needs the openssh-server.

SSH server

Indeed we need to install SSH server to avoid this kind of problem:

So from the Server Ubuntu machine:

sudo apt install openssh-server

This command will install our server and some useful information will be displayed such as:

Creating SSH2 RSA key; this may take some time ...

2048 SHA256:4uYE4j/PDpm189lUD+thFpeTnCggnUWGZ0FQ5w9M9DY root@loginMaster-PC1 (RSA)

Creating SSH2 ECDSA key; this may take some time ...

256 SHA256:bR9DZTPNVtXjBCqPzzra6f7i9lzysvk28ALcNPuHaU4 root@loginMaster-PC1 (ECDSA)

Creating SSH2 ED25519 key; this may take some time ...

256 SHA256:d2GWg8RwpJ8+vJ/p/eB64cy/fv+dpX8j/AnlDKJHrak root@loginMaster-PC1 (ED25519)

These values can be found in the following directory:

  • /etc/ssh/

We have thus:

  • ssh_host_ecdsa_key
  • ssh_host_ecdsa_key.pub
  • ssh_host_ed25519_key
  • ssh_host_ed25519_key.pub
  • ssh_host_rsa_key
  • ssh_host_rsa_key.pub

Which are respectively the private and public keys of each encryption.


Before trying to connect from Client to Server, let's check our IP a last time:


You should see the Client IP address, so:


Let's try mow to connect from Client to Master:

ssh loginMaster@

This time you should see something like this:

The authenticity of host ' (' can't be established.

ECDSA key fingerprint is SHA256:bR9DZTPNVtXjBCqPzzra6f7i9lzysvk28ALcNPuHaU4.

Are you sure you want to continue connecting (yes/no)?

We can see that the public ECDSA key fingerprint is exactly the same as previously generated by the OpenSSH Server (ssh_host_rsa_key.pub):


So we are sure that we are talking to the correct machine.

You can then type "yes" and you'll have this new message:

Warning: Permanently added '' (ECDSA) to the list of known hosts.

And you are invited to enter the password of the Server user login, so in our case enter "pw1".

You should be logged as loginServer onto the Server machine.

To prove it, you can do a:


And you'll see the IP address:


If you see the IP Server on your Client machine then let's continue by exiting from this Server by typing the following command directly on the Client machine:


You are now back to your Client side.

Know hosts

Just after you entered "yes" when asking for continuing connecting, SSH actually added a new line in the following file:

  • /home/loginClient/.ssh/known_hosts

This is something like this:

|1|DAodsjaojlk3j424h329ie=|JdsDJIhjidhsaOPIPOJASDJOhjiuds= ecdsa-sha2-nistp256 sjdnaiodsIONINO84329BGUSADUHI65432ghbjfsdSJDI89kosdajdjsdklsja=

This line is the IP of the Server.

But it's impossible to guess it unless you have the IP and use ssh-keygen.

So if you want to check that you can do the following command:

ssh-keygen -F

And you'll have exactly the same line appearing on your terminal.

So you can be sure that the Server's IP is now known by the Client side.

Client private and public keys

It's time now to generate keys on our Client machine.

You can following my SSH public and private keys tutorial for more information or just do the following command:


You'll be invited to enter a passphrase that is actually a password to protect your private key.

And you need to give this Client SSH public key to the Server machine.

Sharing the Client SSH public key

There are many ways to share this public key.

You can for example use a USB flash drive or whatever you want.

Then copying the line within this id_rsa.pub to the following file:

  • /home/loginServer/.ssh/authorized_keys

But there is also an easiest way by using an SSH command:

ssh-copy-id -i /home/loginClient/.ssh/id_rsa.pub loginServer@

You'll see these messages appear:

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/loginClient/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
loginServer@'s password:

Enter "pw1" as the password for loginServer.

A new message is displayed:

Number of key(s) added: 1

Now try to logging into the machine, with: "ssh 'loginServer@'"

and check to make sure that only the key(s) you wanted were added.

You can now check on the Server folder that a new file has been added:

  • /home/loginServer/.ssh/authorized_keys

Inside you can see the public RSA key from the Client.

So let's try to reconnect from the Client machine to the Server one as suggested by the message:

ssh loginServer@

A new window appears asking:

Enter password to unlock the private key

Enter the passphrase you entered previously when you generated your RSA public and private key pair.

You should be once again on the Server machine directly from your Client terminal.

But this time if you exit:


And try again to reconnect to the Server side:

ssh loginServer@

You'll not be invited to enter your password, because this time the Server trusts the Client side.


This kind of mechanism is present on a lot of platforms and organisations all around the world.

It's then interesting to understand how it works.

If you get all, then good job. laugh

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Enter the characters shown in the image.