• News
  • Security
  • Products
  • About Seqrite
Seqrite Blog Blog
  • News
  • Security
  • Products
  • About Seqrite
Home  /  Application • Education • Network Security • UTM  /  SSH In Nutshell : A protocol for secured network communication
12 August 2019

SSH In Nutshell : A protocol for secured network communication

Written by Sudhanshu Agrahari
Sudhanshu Agrahari
Application, Education, Network Security, UTM
Estimated reading time: 4 minutes

Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. A widely used Transport Layer Protocol, SSH is used to secure connections between clients and servers. SSH was basically designed as a replacement for conventional Telnet and for unsecured remote shell protocols such as the Berkeley rlogin, rsh, and rexec protocols. These protocols send critical information, such as passwords, in plain text format, and are susceptible to interception and disclosure using methods like packet analysis or deep packet inspection. The encryption used by SSH provides confidentiality and integrity of data over an unsecured network, such as the Internet.

                                         Fig. 1: SSH Protocol Stack

How Does SSH Work?

The SSH protocol employs a client-server model for authentication and encryption of data transferred between them.

Negotiating Encryption for the Session

  • Version Exchange: When a TCP connection is made by a client, the server responds with the protocol versions it supports. If the client can match one of the acceptable protocol versions, the connection continues.
  • Key Exchange Initialization: To kick off the key exchange, both sides send a SSH_MSG_KEX_INIT message to each other, with a list of cryptographic primitives they support with their preference. These primitives are basic building blocks, used to perform key exchange and bulk data encryption. The following table (Tab.1) shows some examples of cryptographic primitives.
                                                                                          Tab.1: Cryptographic Primitives

 

  • Diffie-Hellman Initialization: The key exchange begins by the client, generating an ephemeral key pair (private and associated public key) and sending its public key to the server in a, SSH_MSG_KEX_ECDH_INIT message (Fig. 2). The server checks the authorized_keys file of the account that the client is attempting to log into for the key ID. If strict key checking is enabled, and key is not found to be correct, the connection is rejected by the server thereby safeguarding the server from connecting with unknown clients. The key pair created will only be used during the key exchange and disposed afterwards. So, for an attacker it is extremely difficult to steal a private key while passively recording encrypted traffic. This property is called forward secrecy.
                                                   Fig. 2 Generation of the key exchange initialization message

 

  • Diffie-Hellman Reply: On receiving SSH_MSG_KEX_ECDH_INIT message, server generates its own ephemeral key pair. The shared secret key K is generated by server, with its own key pair and client’s public key. After successful generation of shared secret an exchange hash H is generated (Fig. 3). The exchange hash is signed by server to generate its signature HS (Fig. 4).
                                                                 Fig. 3: Generation of the exchange hash H

 

The exchange hash and its signature serve several purposes:

•  The signature or verification loop, of the exchange hash and its signature enables the client to verify whether the server has ownership of the host private key. If yes, the client is connected to the correct server.

• A faster handshake is achieved by signing the exchange hash instead of input to exchange hash.

                                                                  Fig. 4: Generation of the ECDH KEX reply

 

The exchange hash is generated by taking the hash (either SHA256, SHA384 or SHA512, as per the key exchange algorithm) of the following fields:

• Magics M

• Server host public key (or certificate) HPub

• Client public key A

• Server public key B

• Shared secret K

Magics consists of client version, server version, clients SSH_MSG_KEXINIT message and server SSH_MSG_KEXINIT message. With this information in hand, the SSH_MSG_KEX_ECDH_REPLY message can be constructed by the server from the following:

• ephemeral public key of the server B,

• the host public key of the server HPub,

• and the signature on the exchange hash HS.

After SSH_MSG_KEX_ECDH_REPLY is received by client, the client can calculate the secret K and the exchange hash H.

The client extracts the host public key (or certificate) from SSH_MSG_KEX_ECDH_REPLY and verifies the signature of exchange hash HS, hence proving the ownership of the host private key.

In order to prevent Man-in-the-Middle (MITM) attacks, after the signature is validated, the host public key (or certificate) retrieved is checked against a local database of the trusted hosts; if this key (or certificate) is not trusted the connection is terminated.

If you have ever seen a message like below (Fig. 5), it means that the key presented is not in your local database of known hosts.

                                                                          Fig. 5: Prompt for Authentication of Server

Authenticating the User’s Access to the Server

The next stage involves authenticating the user and deciding access. There are various mechanisms for authentication but which mechanism to use depends upon what purpose the server is configured for.

The simplest is password authentication, but this is highly not recommended due to complexities and automated password breaking scripts.

The most popular and recommended alternative is the use of SSH key pairs. SSH key pairs are asymmetric keys. The public key is used to encrypt data that can only be decrypted with the private key. The public key can be freely shared, because, although it can encrypt for the private key, there is no method of deriving the private key from the public key.

Summary

SSH provides a secured encrypted channel for configuration of remote servers, established by agreed cryptographic primitives, and user authentication by symmetric key pairs.

The following diagram shows various stages of SSH handshake in establishing a secured channel that uses a password authentication mechanism.

                                                      Fig. 6: Stages of SSH Handshaking with user Password Authentication

 Previous PostHow should enterprises fill the rising talent gap in cybersecurit...
Next Post  How important is it to understand enterprise security management?
Sudhanshu Agrahari
About Sudhanshu Agrahari

Sudhanshu is a budding developer with experience of 1.8 years. He holds a Post-Graduate Diploma in Embedded System Design from CDAC-ACTS Pune. In this time span...

Articles by Sudhanshu Agrahari »

Related Posts

  • Is accelerating enterprise digital transformation leading to cyberthreats?

    Is accelerating enterprise digital transformation leading to cyberthreats?

    November 25, 2020
  • Discover ‘GNU Make’, an amazing tool for building application code.

    The Evergreen ‘Make’ Utility: A cost-effective way of deployments on Cloud.

    October 1, 2020
  • Why should businesses boost the immunity of Legacy Systems?

    Legacy Systems longing for enterprise attention?

    August 6, 2020

No Comments

Leave a Reply.Your email address will not be published.

Cancel reply

CAPTCHA Image
Refresh Image

Popular Posts

  • RAT used by Chinese cyberspies infiltrating Indian businesses RAT used by Chinese cyberspies infiltrating Indian businesses December 18, 2020
  • Benefits of having Intrusion Prevention/Detection System in your enterprise Benefits of having Intrusion Prevention/Detection System in your enterprise February 15, 2018
  • 5 Security measures you should take to protect your organization’s network 5 Security measures you should take to protect your organization’s network August 11, 2017

Featured Authors

  • Seqrite
    Seqrite

    Follow us for the latest updates and insights related to security for...

    Read more..
  • Viraj Talikotkar
    Viraj Talikotkar

    Viraj is a Lead Technical Writer at Quick Heal Technologies. He is always on...

    Read more..
  • Sanjay Katkar
    Sanjay Katkar

    Sanjay Katkar is the Joint Managing Director and Chief Technology Officer of...

    Read more..

Latest Posts

  • Are we prepared against risks generating from the IoT revolution?

    Are we prepared against risks generating from the IoT revolution?

    January 15, 2021
  • Proactiveness is the key to resolving hybrid cloud’s security challenges

    Proactiveness is the key to resolving hybrid cloud’s security challenges

    January 6, 2021
  • How can EdTech companies deal with rising security challenges?

    How can EdTech companies deal with rising security challenges?

    December 24, 2020

Stay Updated!

Topics

Antivirus For Linux (10) Antivirus For Server (9) BYOD (9) Cyber-attack (31) cyber-attacks (56) cyberattacks (12) Cybersecurity (274) cyber security (25) Cyber threat (29) cyber threats (44) Data (10) data breach (50) data breaches (27) data loss (28) data loss prevention (33) data protection (21) data security (13) DLP (49) Encryption (16) endpoint security (102) Enterprise security (14) EPS (9) Exploit (12) firewall (11) hackers (9) incident response plan (9) IoT (10) malware (58) malware attack (22) malware attacks (12) MDM (25) mobile device management (9) Network security (18) Patch Management (12) phishing (16) Ransomware (54) ransomware attack (29) ransomware attacks (30) ransomware protection (12) Seqrite (24) Seqrite Encryption (27) Seqrite EPS (33) Seqrite Services (16) UTM (34) Vulnerability (10)

Products

  • Endpoint Security (EPS)
  • Seqrite Encryption Manager
  • Seqrite Endpoint Security Cloud
  • Cloud Security
  • Seqrite mSuite
  • Seqrite MobiSMART
  • Unified Threat Management
  • Seqrite Secure Web Gateway
  • Antivirus for Server
  • Antivirus for Linux

Resources

  • White Papers
  • Datasheets
  • Threat Reports
  • Manuals
  • Case Studies

About Us

  • Company Overview
  • Leadership
  • Why choose SEQRITE?
  • Awards & Certifications
  • Newsroom

Archives

  • By Date
  • By Category

© 2020 Quick Heal Technologies Ltd. (Formerly Known as Quick Heal Technologies Pvt. Ltd.) Cookie Policies Privacy Policies

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website.
By browsing this website, you agree to our cookie policy.