SSH workings and key-exchange procedure

                    Reachability is a less problem compared to security of the route to target. Even though we had many tools to access a remote server yet, Secure Shell(SSH) is ubiquitous the reason is security. The motivation for SSHcreated in 1995 by Finland native Tatu Ylönen, came in response to a password-sniffing attack at his university. Emphasis on security and encryption.

     How does SSH work?

  1. When we execute ssh user@Host3 from Host2, there is exchange of keys between them.
  2. In case, connecting first time SSH will prompt to verify the key and store it.
  3. Then based on authentication type defined SSH will prompt user for password or allow session to be created without password.
  4. The key transferred keep the communication encrypted and SSH supports various encryption methods.
      Few important question that comes forward, what are these keys?, Where are the keys get stored?  Where to define authentication  type? What are various method of encryption? I try to answer them one by one.

  •     What are these keys?  Keys are meant to open secrets. Each must be unique and can be shared with trusted ones. The communication channel between two host is secured in phased manner. First phase, both parties agree on a secret key that encrypt the messages passed between them, this process is done using key exchange algorithm, and this type of encryption is known as Symmetric encryption. This initial key exchange comes to a user screen as a prompt to accept and verify the connection coming from a trusted host. This is done prior to authenticating a client.
  • Where are the keys get stored?  Secret key get stored in ~/.ssh/known_hosts file
  • Where to define authentication type?  /etc/ssh/sshd_conf file
  • What are the various method of encryption? There are variety of different symmetrical cipher systems, including AES, Blowfish, 3DES, CAST128, and Arcfour. The server and client can both decide on a list of their supported ciphers, ordered by preference. The first option from the client’s list that is available on the server is used as the cipher algorithm in both directions.

      SSH Authentication

                        It is Second phase to secure channel. Authentication with password and without password.  Password should be know to the party to access the channel and create a session for communication. In case party needs password-less authentication, asymmetric encryption is used to do the setup. Asymmetrical encryption two associated keys are needed, One of these keys is known as the private key, while the other is called the public key. The public key can be freely shared with any party. The private key should be kept entirely secret and should never be shared with another party.
                        The client creates a key pair and then uploads the public key to any remote server it wishes to access. This is placed in a file called authorized_keys within the ~/.ssh directory in the user account’s home directory on the remote server.

Authentication using SSH key pairs the procedure happens like this:

  1. The client begins by sending an ID (fingerprint) for the key pair it would like to authenticate with to the server.
  2. The server check’s the authorized_keys file of the account that the client is attempting to log into for the key ID.
  3. If a public key with matching ID is found in the file, the server generates a random number and uses the public key to encrypt the number.
  4. The server sends the client this encrypted message.
  5. If the client actually has the associated private key, it will be able to decrypt the message using that key, revealing the original number.
  6. The client combines the decrypted number with the shared session key that is being used to encrypt the communication, and calculates the MD5 hash of this value.
  7. The client then sends this MD5 hash back to the server as an answer to the encrypted number message.
  8. The server uses the same shared session key and the original number that it sent to the client to calculate the MD5 value on its own. It compares its own calculation to the one that the client sent back. If these two values match, it proves that the client was in possession of the private key and the client is authenticated.

Comments

Popular posts from this blog

About sshd_config file