SSH- {S}ecure {SH}ell Protocol

The purpose of SSH, why it was needed, and how things were before SSH?

Before the internet became widely available, computers needed a way to communicate with one another. They did this through a protocol called telnet.
Telnet allowed computers to connect and exchange information. There wasn't a big issue with telnet not being secure at first because all communication was intranet-based or network-to-network.

Need:
But when the internet came along, it introduced the need for secure communication between a client and a remote server that is outside the network.

Purpose:
SSH allowed computers to communicate with each other in a way that was more secure than telnet. With SSH, the communication between the computers was encrypted, so it was harder for someone to eavesdrop on the conversation.

What is SSH protocol?

Secure Shell (SSH) is a network protocol that allows you to connect to a remote computer securely.

That means all SSH traffic is encrypted, which means that any data you send or receive over an SSH connection will be scrambled and unreadable to anyone who does not have the decryption key. This helps to protect your data from being intercepted or modified by third parties.

In what areas does SSH find the application?

A variety of tasks can be accomplished with SSH, including remote administration, file transfers, and secure communications. The tool is popular among system administrators

The real-world SSH setup will consist of the following components

1. Server machine:
   We need to connect to this machine and try to control/access it remotely. This machine needs to be configured with OpenSSH Server software first.

2. Client machine:
   The client from where we will try and access the remote machine/server.
   This machine should have a way to connect to the SSH server.

   • Linux and Mac machines will have SSH clients installed by default.

   • On Windows, we can install PuTTY or git-bash to communicate using SSH protocol.

3. Authentication (bird's eye view, in detail explained below):

   • Password

   • Public/private keys

An example of password-based authentication is:

Syntax: ssh {user-id}@{ipaddress}  => ssh root@192.165.3.2 [To access the machine with IP address, you will need root's password]

Keys that are public and private:

ssh-keygen or ssh-keygen -t rsa
- The location (must be provided) and passphrase (optional) will be requested
- This will create two keys, a public key and a private key.
- The public key needs to be shared. [.pub file]

SSH-copy-id {user}@{ip-address}
      or
It is possible to access an SSH server via a browser, such as github or gitlab. Log in to your account and go to the SSH section and upload your public key.

TLS/SSL vs SSH? Are they even different?

Both TLS/SSL and SSH use transport layer protocols [widely used TCP] to communicate.

Difference:

1. TLS enables connections to be encrypted without authentication or authenticated without encryption. SSH, on the other hand, encrypts and authenticates all connections.

2. When using TLS, only the server is authenticated with a key pair.

   • SSH uses a separate key pair to authenticate each connection:

     • One key pair for a connection from a local machine to a remote machine.

     • A second key pair is to authenticate the connection from the remote machine to the local machine.

SSH Protocol Architecture

SSH uses three different transport layer protocols:

• SSH Transport Layer Protocol: Used for server authentication and data confidentiality.

• SSH User Authentication Protocol: Used for authenticating users.

• SSH Connection Protocol: allows for multiple logical connections over a single SSH connection.

  • The SSH connection protocol allows for multiple logical connections over a single SSH connection. Rather than having only one logical connection between server and client, multiple channels are created.

    An example would be to have one channel for port forwarding and another for session management.

SSH data packet structure

• Packet size

• Another byte mentioning the padding length

• Payload

• Actual padding [This enhances the encryption level and makes it more difficult for someone to decrypt it]

• message-auth-code [It helps verify that a message is not a random packet but from a valid user or machine]

  • The whole packet, excluding the packet length and message auth code, is encrypted.

  • The encryption algorithm and message auth code are decided by the client and server at the beginning, based on which ones they offer.

SSH Communication between client and server occurs

1. A TCP connection is established between the two machines [Three-way handshake].

   • It doesn't matter what kind of connection you use - as long as it's reliable, any connection will work for this purpose. For example, websockets or RS-232 connections are both fine.

2. As shown in the diagram above, SSH breaks the data into packets and encrypts them.

3. Data exchange happens when a series of channels are opened on top of TCP, and encrypted data packets are sent through those channels.

Post TCP connection, how authentication takes place in SSH protocol

• Step 1: [Identification string]

  • a. The client sends an identification string that includes the SSH protocol version and software version.

  • b. The server responds with its own identification string, including the SSH version and software version.

• Step-2: [Key Initialization Message]

  • a. The client sends over encryption, KeyX, message authentication, and compression.

  • b. The server does the same in return.

    • Depending on the situation, the server might pick up the first encryption algorithm from the client.

• Step-3: [Key Exchange Phase]

  • a. The client uses Deffie-Hellmen or Elliptic-curve DeffiHellamn to generate a pair of keys, one private and the other public.

  • b. The client then sends the public key to the server via SSH_MSG_KEX_ECDH_INIT.

  • c. Once the server receives the key, it will generate its own public and private keys.

    • 1. The server then uses all three keys to compute secret key: the public server key, the public client key, and the private server key.

    • 2. The server then computes a hash using a mutually agreed hashing algorithm. The hashing algorithm used will be agreed upon in a previous step.

    • 3. For the hashing algorithm, the server takes the following as input:

      • Step-1a + Step-1b + Step-2a + Step-2b + step-3c [excluding server private key] + secret key + public host key used by server for asymmetric algorithm

      • Output : a hash will be generated.

    • 4. server will encypt this hash using its private key generated in step-3c.

  • d. The server then sends a reply[SSH_MSG_KEX_ECDH_REPLY] to the client over SSH that includes an encrypted hash, the host's public key, and the client's public key.

  • e. The client can then use the server's public key as input to a Diffie-Hellman key calculation, in addition to the client's own Diffie-Hellman public and private keys, to generate a shared secret key.

  • f. The client will then generate a hash using the same hashing algorithm and with the same inputs as in step-3c-3. If the hashes match, the client is authenticated.

• Step-4: [Encrypted data communication]

  • The secret keys that were generated will not be used for encryption or decryption.

  • Instead, this secret key is used to generate 6 new keys:

    • Two keys for encryption between the server to the client and client and vice versa.

    • Two keys for initialization vectors from the server to the client and vice versa.

    • Two keys for integrity checks from the server to the client and vice versa.

• At the end of the key exchange, both parties will receive an SSH_MSG_NEWKEYS message, signaling that they can now start using the new keys to encrypt and decrypt.

• The final step in establishing a client connection is when the client sends an SSH_MSG_SERVICE_REQUEST and the server accepts it with an SSH_MSG_SERVICE_ACCEPT message.