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.
sudo apt install net-tools
We can now see our IP address with the following command:
ifconfig
Your IP is next the "inet" word, something like that:
inet 192.168.40.1 netmask 255.255.255.0 broadcast 192.168.40.255
So do the same with your both Linux distributions.
Let’s say that we have eventually the following configuration:
Then let's say that we have 1 user on each machine with the corresponding password like that:
Let's now try to talk from Client to Server:
ssh loginMaster@192.168.40.1
You should have the following message:
ssh: connect to host 192.168.40.1 port 22: Connection refused
or
ssh: connect to host 192.168.40.1 port 22: Connection timeout
It's normal because our Server needs the openssh-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:
We have thus:
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:
ifconfig
You should see the Client IP address, so:
Let's try mow to connect from Client to Master:
ssh loginMaster@192.168.40.1
This time you should see something like this:
The authenticity of host '192.168.40.1 (192.168.40.1)' 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):
bR9DZTPNVtXjBCqPzzra6f7i9lzysvk28ALcNPuHaU4
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 '192.168.40.1' (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:
ifconfig
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:
exit
You are now back to your Client side.
Just after you entered "yes" when asking for continuing connecting, SSH actually added a new line in the following file:
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 192.168.40.1
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.
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:
ssh-keygen
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.
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:
But there is also an easiest way by using an SSH command:
ssh-copy-id -i /home/loginClient/.ssh/id_rsa.pub loginServer@192.168.40.1
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@192.168.40.1'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@192.168.40.1'" 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:
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@192.168.40.1
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:
exit
And try again to reconnect to the Server side:
ssh loginServer@192.168.40.1
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.
Add new comment