Skip to content

SSH (Secure Shell).md

Latest commit

 

History

History
30 lines (25 loc) · 2.47 KB

SSH (Secure Shell).md

File metadata and controls

30 lines (25 loc) · 2.47 KB

Explanation

  • SSH stands for Secure Shell and provides a safe and secure way of executing commands, making changes, and configuring services remotely.
  • When you connect through SSH, you log in using an account that exists on the remote server.

Authentication Mechanism

  • Clients generally authenticate either using passwords (less secure and not recommended) or SSH keys, which are very secure.

Password Authentication

  • Password logins are encrypted and are easy to understand for new users.
  • However, automated bots and malicious users will often repeatedly try to authenticate to accounts that allow password-based logins, which can lead to security compromises.
    • For this reason, it's recommended always setting up SSH key-based authentication for most configurations.

SSH Keys Authentication

  • SSH keys are a matching set of cryptographic keys (public and private) which can be used for authentication.
    • The public key can be shared freely without concern,
    • while the private key must be vigilantly guarded and never exposed to anyone.
  • To authenticate using SSH keys, a user must have an SSH key pair on their local computer.
  • On the remote server, the public key must be copied to a file within the user’s home directory at ~/.ssh/authorized_keys.
    • This file contains a list of public keys, one-per-line, that are authorized to log into this account.

Steps

  1. When a client connects to the host, wishing to use SSH key authentication, it will inform the server of this intent and will tell the server which public key to use.
  2. The server then checks its authorized_keys file for the public key, generates a random string, and encrypts it using the public key.
    • This encrypted message can only be decrypted with the associated private key.
  3. The server will send this encrypted message to the client to test whether they actually have the associated private key.
  4. Upon receipt of this message, the client will decrypt it using the private key and combine the random string that is revealed with a previously negotiated session ID. It then generates an MD5 hash of this value and transmits it back to the server.
  5. The server already had the original message and the session ID, so it can compare an MD5 hash generated by those values and determine that the client must have the private key.

Sources