Skip to content

SSH

How does SSH work? Related: Networking#TLS Handshake TLDR

Symmetric Encryption

  • Where can be be used to encrypt and decrypted
  • Called a shared secret
  • Used to pass the messages back and forth
  • The key generated during a connection is session based
  • The key is established prior to authenticating the client
  • Ciphers for symmetric key generation:
    • AES, Blowfish, 3DES, CAST128, and Arcfour etc

Asymmetrical keys

  • only used for authentication
  • The mathematical relationship between the public key and the private key allows the public key to encrypt messages that can only be decrypted by the private key.
  • This is a one-way ability, meaning that the public key has no ability to decrypt the messages it writes, nor can it decrypt anything the private key may send it.
  • SSH key pairs can be used to authenticate a client to a server.
    • 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.
    • Key based authentication
      • Server will create a challenge message with the public key
      • Client will prove it has the private key by decrypting it
      • Server allows authentication

Hashing

  • hashes are mainly used for data integrity purposes and to verify the authenticity of communication. The main use in SSH is with HMAC, or hash-based message authentication codes. These are used to ensure that the received message text is intact and unmodified.
  • As part of the symmetrical encryption negotiation outlined above, a message authentication code (MAC) algorithm is selected. The algorithm is chosen by working through the client's list of acceptable MAC choices.
  • The MAC is calculated from the symmetrical shared secret, the packet sequence number of the message, and the actual message content.
  • The MAC itself is sent outside of the symmetrically encrypted area as the final part of the packet. Researchers generally recommend this method of encrypting the data first, and then calculating the MAC.

Stages

Stage 1

Agree upon and establish encryption to protect future communication. Accomplishes the task of generating an identical shared secret without ever having to send that information over insecure channels.

The basis of this procedure for classic Diffie-Hellman is: - Both parties agree on a large prime number, which will serve as a seed value. - Both parties agree on an cipher (typically AES), which will be used to manipulate the values in a predefined way. - Independently, each party comes up with another prime number which is kept secret from the other party. This number is used as the private key for this interaction (different than the private SSH key used for authentication). - The generated private key, the cipher , and the shared prime number are used to generate a public key that is derived from the private key, but which can be shared with the other party. - Both participants then exchange their generated public keys. - The receiving entity uses their own private key, the other party's public key, and the original shared prime number to compute a shared secret key. Although this is independently computed by each party, using opposite private and public keys, it will result in the same shared secret key. - The shared secret is then used to encrypt all communication that follows.

Stage 2

Authenticate the user and discover whether access to the server should be granted. - simplest is probably password authentication, in which the server simply prompts the client for the password of the account they are attempting to login with. The password is sent through the negotiated encryption, so it is secure from outside parties. - Not recommended because scripts can break passwords, especially easy ones - Client send ID for the key pair it wants to authenticate with - Server checks the authorized_keys fo a match - If found, encrypted a random # with the public key - Send to client - Client decrypts and sends back hash of key - Server also hashes, compares, and hopefully says, "Cool"