SSH: The Portal Between Two Computers

Introduction

Did you ever wonder what is the most secure way to connect two computers remotely, while sharing files?

Or, is there any way we can keep two systems connected like a portal without needing to enter passwords repeatedly while keeping the systems secure?

The answer to this is YESSS!!! 🥳

We can do all that using... 🥁

SSH!!

Sounds pretty cool, right?

In this blog, we are gonna talk about SSH, and how we can share files as well as control and modify remote computers over the internet with encryption.

Before understanding it, let us know what are protocols first because SSH is a type of protocol.

Protocols

Protocols are an agreement by which machines 💻 communicate with one another. we can say it's the language in which the computers communicate with each other.

A few examples of protocols are:

• HTTP (Hypertext Transfer Protocol) → Allows users to share files like HTML, CSS, and JS between browser(client) and server.
• HTTPS (Hypertext Transfer Protocol Secure) -> It's similar to HTTP with the additional advantage of encryption to protect the files from third parties.
• FTP (File Transfer Protocol) -> Allows us to send files as well but is often used to upload files on hosting platforms.
• IMAP (Internet Message Access Protocol) -> Allows us to send emails.📧
• SSH (Secure Shell Protocol) -> It allows users to share files and control and modify remote computers over the internet.

and a lot more protocols are there...

Now you might be thinking then what exactly is the difference between HTTPS and SSH? as both are a way to communicate and are encrypted. 🤔

The main difference between HTTPS and SSH is, HTTPS is only used in transferring files between browser and server and showing a website, whereas SSH is a shell to exchange or communicate between two devices and not just browsers. A shell allows us to talk to OS directly.

In Short,

• SSH -> communication b/w two computers using a secure shell.
• HTTPS -> communication b/w browser and server

In an SSH connection, there are 2 computers involved:

• host: The host refers to the remote server you're trying to access.
• client: The client is the computer you're using to access the host.

SSH Command

Now, let's see how exactly can we use SSH. We can simply run the SSH command in our terminal: ssh {user}@{host}.

• If we break it down, here:
  • ssh: This command instructs the system that we want to open an encrypted secure shell connection.
  • user: The user represents the account you want to access. eg. if you want to access as system admin you can use root which is by default in many systems.
  • host: Host refers to the computer you want to access, which can be an IP or a domain name.

For example, ssh root@192.168.5.2

In this, ssh lets the OS know we are going to initialize a shell connection , the root is the user (Fun Fact: root is often the default configuration used for admin 👨‍💼 access on servers) and 192.168.5.2 is the IP Address of the server we are trying to get into.

If you are using Linux or Mac, then using SSH is pretty straightforward, but in case you can't: makeuseof.com/tag/beginners-guide-setting-s..

But in the case of Windows, we need to utilize an SSH client to open SSH connections, and the most popular one for Windows is called "Putty."

You can use the following resource for Windows:

• PuTTY: mediatemple.net/community/products/dv/20440..
• Windows 10: howtogeek.com/336775/how-to-enable-and-use-..
• Extra:
  1. ssh.com/ssh/putty/windows
  2. memset.com/docs/server-security/secure-comm..

Now after setting it all up, 🥹 you must be wondering, " But why? why do we(Software Developers/Engineers) need it? What's the point of all this? 🥲"

Why SSH is important for you as a Software Developer?

SSH is an essential concept for developers because we will have to use it all the time during our careers.

Some examples:

• Connecting to GitHub, cloning, pushing, or pulling the files from their servers to our computers so we don't have to use HTTPS and enter passwords all the time to clone a repo.
• To access your computer remotely.
• Finally, Deploying your production applications on the servers. 😳

Okay, so now you understand why we need it. But how does SSH actually work?

Let's try to understand that! Also please grab yourself a coffee ☕️or chai :) because it's gonna be a long read and needs your attention!

So, get caffeinated, and Let's begin... 🔥

How SSH Works?

To understand how SSH works we need to understand the 3 techniques used in SSH:

1. Symmetrical Encryption
2. Asymmetrical Encryption
3. Hashing

Before understanding these, do you see the word "Encryption" here? What exactly is that?

So, Encryption is a way to hide or jumble up a piece of information so that it's impossible for a third party to get the report without having some sort of way to decrypt it.

Symmetrical Encryption

• Symmetric Encryption uses one secret key for both the encryption and decryption by both parties.
• Let's understand it with an example:
• Let's assume we want to send a string "Abhinav's Secret" as data.
• Here in the first user we are encrypting our data ie."Abhinav's Secret" with the key i.e. K1 which is outputting a random string.
• Now, we can send this random gibberish encrypted string directly to the second user. and no third parties can understand this gibberish.
• The Second User can decrypt this random encrypted string using the same key(K1) and get the original string back which was "Abhinav's Secret".

So again with symmetric encryption, anyone who possesses a key can decrypt the message being transferred. And SSH communicates through this shared key.

This looks nice but what is one problem you notice here?👀 Can you think of any?🙃Well anyone that has the key can decrypt the message.

• So I was sending something important over to another computer. If somehow a third party happens to find the key, they can find out the information and can decrypt this message just by using the same key as us.
• We have to get this key securely so that other people can't use it as well or can't find out what it is. And this is done through what we call a Key Exchange Algorithm.
• What makes this algorithm particularly secure is that the key is never actually transmitted between the client and the host. Instead, the two computers share public pieces of data and then manipulate them to independently calculate the secret key.

But it must be noted that the secret key is specific to each SSH session and is generated prior to client authentication.

So once the key has been generated between these two parties, all packets moving between these two machines must be encrypted with this key. Therefore using symmetrical encryption, we are able to communicate in a private way.

Asymmetrical Encryption

• In Symmetrical Encryptions, we got to know we need some kind of a Key Exchange Algorithm and this key exchange algorithm is something called Asymmetrical Encryption.
• Unlike Symmetrical Encryptions, asymmetrical uses 2 different keys for encryption and decryption (Private and Public Key).
• As we can see in the diagram, we have 2 keys for each computer. which include one private and public key.

So what do you think can be the function of these?

• They are pretty self-explanatory so the public key is out in the open you can share it will anyone, but the private key is something that has to be kept very very securely and never be shared with anyone.
• This forms a private-public key pair and these keys are linked with each other in terms of functionality in a way that, the message which is encrypted with the public key can only be decrypted by the same machine's private key. this is what we call a One Way Relationship.

Let's take an example,

• If we share our public key with our friend and he also shares his with us.
• Now, We have his Public key right? and now if we encrypt some data let's say "Password123" with his Public key which we received and send the encrypted data(assume its a random gibberish string "E+345sd$") to him.
• Now, he can decrypt it using his private key and get the data which was "Password123" string as both the keys have One Way Relationship as I mentioned before.
• As we can see the strength of this type of encryption is the private key is never relieved or shared, right? which is pretty amazing!

Do we always use Asymmetrical Encryption?

• Now most people assume that we use Asymmetrical Encryption in all types of SSH connections entirely which isn't wholly accurate.
• Actually, this connection is only used during the Key Exchange Algorithm of Symmetric Encryption.
• If you can recall, we only need one key to be exchanged for the entire connection in Symmetrical Encryption, so we use Asymmetrical encryption only to exchange that key in a secure fashion.
• So, Whenever a new SSH connection is being initiated, both parties generate temporary public and private keys and share the respective public keys with one another at this point, we are able to get the symmetric key so we can exchange information using something called Diffie Hellman Key Exchange.

Diffie Hellman Key Exchange: Makes it possible for each party to combine their own private data with public data from other systems to arrive at an identical secret session key. Woah! 🥵 seems confusing? Don't worry I am attaching a few resources which you can use to understand it better. ☺️

• youtube.com/watch?v=NmM9HA2MQGI
• youtube.com/watch?v=Yjrfm_oRO0w
• youtube.com/watch?v=vsXMMT2CqqE
• youtube.com/watch?v=NF1pwjL9-DE

• By now we should know how we are able to generate a symmetric key using asymmetrical encryption, using the Diffie Hellman Key Exchange. And in this way, the Symmetrical Key is going to stay private to us.

Isn't it kind of funny?

• That is the name of the "Key Exchange" because we aren't actually exchanging the keys 🥹otherwise, it will be out in the public which we never want to happen! we actually just share pieces of public variables such as our public keys from each computer and we generate the key separately in our own private space.

Also, now you might be thinking: Fine! enough about all these encryptions 🥲

But trust me, these types of encryptions are everywhere!

You are probably using it right now while reading this blog!

To read this blog, you are using Diffie Hellman Key Exchange or when we use our phone to use anything when it connects to a server, it uses Diffie Hellman Key Exchange, and as a developer, we should know how these things work, right? and not just on the surface level.🥹

So to summarize we learned everything till now, SSH uses both symmetric and asymmetric encryption, since asymmetric encryption is more time-consuming most SSH connections use symmetric encryption as we have discussed.

The idea behind this is that asymmetric encryption is used to share only the public key. Then finally, use that key symmetric encryption for further communication, so it's swift.

Once secure symmetric communication has been established. The Server uses the client's public key and generates a challenge which is transmitted to the client for authentication. If the client successfully decrypts the message, the client holds the private key required for connection, and the session finally begins.

There is again one issue in this whole connection. What if a third party tries to act as the client or server and temper or modify the data if they somehow convince the client that they are the host or vice versa they can exchange the keys with them and the information can flow thru that middle man.

To solve this issue, we will talk about something called hashing.

Hashing

• Hashing is a form of cryptography used in SSH.
• Hashing differs from the other two forms of encryption discussed because they are never meant to be decrypted anywhere.
• They simply generate a unique value of a fixed length for each input that it gets.
• They are one way ie. if I hash "Abhinav's Secret" it's going to run some function and return some gibberish really quickly with the trick being we have no idea how to get the original string back.

So how is that useful? As we mentioned before, SSH is able to transfer messages securely but to prevent duping by third parties, we can use hashes to authenticate the information so the third party can't temper or modify the information.

• This is done using something called Hash-based message authentication code (or HMAC).

So the gist of this is:

• Using a hash function, each message that is transmitted must contain something called a MAC.
• This MAC is a hash generated using a combination of the symmetric key, packet sequence number, and message content that we are sending. MAC = Symmetric Key + Packet Sequence Number + Message When a host initiates a session, its packet sequence number is a random number.
• And then this MAC is sent to the recipient.

Let's take an Example,

• Let's say we are sending a message ie. "Abhinav's Secret" to a host.
• We run a hash function on a combination of the symmetric key + packet sequence number + our message ie. "Abhinav's Secret" which gives an output of gibberish string ie. "f#er*fgfgdg#%Y#423" which we call as MAC.
• Then now, we send this MAC directly to the host.
• Now when the host receives this Mac, it can compare the received MAC with generating a MAC on its own.
• As it has the same information ie. they can use their own symmetric key that is the same as the client, they can use the packet sequence number as they both know it, and then as this message was sent using SSH they both have the message as well.
• And if both have all the information similar to each other, the MAC will be exactly the same ie. "f#er*fgfgdg#%Y#423".
• In this way we will avoid any tempering or modification of data as if in any way the message, i.e., "Abhinav's Secret" was being tempered even by one letter or a Capitalization happen, the whole hash will be completely different
  • And that's a characteristic of hash functions, if we change any single thing, no matter how similar the inputs may be, the whole hash changes.

Authentication

• Still, one part remains, which is to authenticate the user. We wanna make sure who even is trying to communicate with the server has the proper access to it.
• Now, there are two ways you can authenticate the user.
• The first is using the password but it's not the preferred approach, Why? Because the issue with passwords is you can simply use a bot and brute force it, then it's not the best way to secure a server with it. So what can be a better option?
• A better way to authenticate is by using SSH itself, we can generate a pair of ssh keys(public and private keys) using the ssh-agents and save them in our .ssh file in the root. Then add the public key(which will have an ending with .pub) to the server account settings.

To understand the authentication part even better, I am attaching a few resources: docs.github.com/en/authentication/connectin.. 
inmotionhosting.com/support/server/ssh/how-..

Woah! That was a lot of information! 😳 But it's enjoyable to understand things deeply and how they work!

Conclusion