Welcome back everyone, it’s gutsytechster!!
Well, we know about SSH from the previous blogs. If you haven’t read that blog, I’ll suggest you to read that first, so that you can easily get the things. You can refer that on Do you know SSH? This time we are going to go into depth with SSH to know its workflow, and exactly how does it work? Let’s start then with a great zeal !
We know that Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. The best known example application is for remote login to computer systems by users.
Some important attribute which can enhance the working of remote login are:
- The connection should be secured to prevent eavesdropping.
- The authentication of data should be done by checking if the incoming information is coming from the expected user.
- The identity of both server and client must be known to each other.
Luckily, all the above enhanced features are included in SSH alongwith some of its unique features.
SSH protocol has different versions in which widely used are SSH version 1 and SSH version 2. The current default version is SSH 2. I will be discussing both versions one by one.
SSH Protocol Version 1
The first step to establish an SSH connection is to create the secure channel between server and client. This is done with the help of Public key cryptography or Asymmetric cryptography. From previous blogs, you now know the symmetric and asymmetric cryptography. If you have any doubt you can refer following blogs:
But many a times we misinterpret the thing that public key cryptography is used to encrypt the session, while it is not true. Asymmetric encryption is more complex due to which it has slow data rates as compared to symmetric encryption. So, SSH uses Public key cryptography to exchange the secret key which is used to establish the symmetric cryptography. In short “Asymmetric encryption is used to share the secret key which is then used to establish symmetric encryption. “
Now, when a secure channel is established, firstly client authenticates the server as client is the one to initiate the session. So let’s do it step by step.
Step 1. As I have mentioned that the connection is initiated by the client, the first step is to establish a TCP connection to port 22 on the server. The client gets two main information from above connection. One is protocol version supported by the server and second the SSH server package(This should be kept private). Now, if server supports version 2 protocol, the client will continue, otherwise will break the connection.
Step 2. As soon as the client continues based on the protocol version supported by the server, server and client will now switch to a “Binary Packet Protocol”. This protocol contains a packet length of 32 bits. For more details on this protocol, you can refer to this.
Step 3. Now the server will send some analytical information to client which will have an important role in current login session. These are:
1. The server will disclose its identity to the client by providing it with its rsa public key.(Initially both client and server have generated their public and private key pair). If the client is connecting for the first time, then it will get a warning like this:
The authenticity of host '184.108.40.206 (220.127.116.11)' can't be established. ECDSA key fingerprint is 4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67. Are you sure you want to continue connecting (yes/no)?
You wil get the above warning for the first time. After the first connection the identity of the server i.e. the host key wil be saved in the known_hosts file. The thing is that this key is host(machine) identity and not the user. So if you’ll try to connect another machine then you’ll get the same warning again as the host key would be different that time.
2. The second information provided by the server will be server key which is exchanged from server to client. This method is not used in SSH version 2. This key is regenerated every hour.It’s default size is 768 bits.
3. Client then sends 8 random bytes, which are also known as checkbytes, in reply to the server.
4. Finally server provides all the supported encryption algorithms and authentication methods.
Step 4. From the list of encryption algorithms supported by the server, the client generates a random symmetric key(also known as session key) and sends that to the server. This symmetric key is used to encrypt as well as to decrypt the data.
The client sends this symmetric key by doing double encryption, first by the public rsa key of server and then by the server key provided by the server. This increases the security as if somehow anyone got the corresponding private key of server, he or she won’t be able to decrypt the data as the server key is also used for encryption, which is changing every hour. Alongwith the session key, the client also sends the selected algorithm from the list of algorithms provided by the server.
Step 5. If you have observed, Client hasn’t authenticated the server. It only has its identity of the server which is its host key(rsa public key). It is very important to authenticate the server to confirm whether the server’s host key send, was from the intended server.
In order to authenticate the server, the client needs to be sure that the server has decrypted the session key. So after sending the session key, the client waits for the confirmation message from the server. The confirmation message should be encrypted with the same session key which the client send. Once the client get the confirmation message, the communication can be started.
But another thing to be noted is that upto now only server is authenticated not the client. Authentication of client has same importance as authentication of server. So client can be authenticated by using password, using pubic key, by Rhosts etc. We will see for the password and public key.
It is a simple method and most commonly based authentication method, in which the client is prompted to enter the password of the account, it is trying to login with. One thing to be observed is that the password shared, is encrypted with the same session key. Even though the password is protected, the method is not generally used due to complexity of password. Brute force can break password of normal length very easily as compared to other authentication method.
Public Key authentication
The most secure method to authenticate the client is Public key authentication. The client has its rsa private and public key pair, which he already created initially. To know how to create rsa key pair, you must’ve read the post “Do you know SSH?“. Keep in mind that this key pair is not for encrypting the data to be transferred, it is used to provide a secure channel to exchange the session key.
Now the client will share the content of it’s file id_rsa.pub with the server, which would be stored in the file authorized_keys on the server.
Now, let’s go back to the step 5, where we stopped.
From the list of supported authentication methods provided by the server, the client will select the public-key authentication and also send the details of encryption used for this authentication.
The server, on receiving the public key authentication request, will generate a random 256 bit string encrypted with client’s public key as a challenge. The client on receiving the challenge, will decrypt it with its private key. Then it will generate a md5 hash value by combining the decrypted challenge with the session key. This hash value is then send to the server. The server regenerate the hash value as both the challenge string and session key is possessed by the server also. If both the hash value generated by server and the client matches, the client will be authenticated.
SSH Protocol Version 2
It is most common ssh protocol version used these days. The workflow of SSH version2 is almost same as that of version 1,still it has some advanced features which makes it a norm.
As we know now that in SSH version 1, the client is provided with the server’s host key and the server key which changes hourly. The client then select an algorithm and generates a random session key which has to be used in encryption and sends that session key with double encryption using host’s key and server key. But in SSH version 2, there is no concept of server key, rather it uses the Diffie-Hellman algorithm which we have covered in our previous blog. The main concept behind this algorithm is that no single party should decide the server key(as in previous version, client decides the session key).
Well, there are other differences in SSH versions, you can regard them here. But if you say in simple words, then SSH 2 is advanced version of SSH 1.
With this, we have reached the periphery of this blog. I hope, I would be able to convey whatever I learnt. Well, then meet you in the next blog.
Be curious !