Detail and SSH connection

Symmetrical Encryption

• One key can be used to encrypt messages Alice->Bob but can also be used to decrypt messages Bob->Alice.
• Anyone that holds the key, can encrypt and decrypt messages.
• AKA “Shared Secret” || “Secret Key”
• SSH uses Symmetrical encryption for the connection contrary to what most people believe (asymmetric). Asymmetric encryption is only used for authentication.
• Key Exchange Algorithm
  • Using an algorithm, the client and server can exchange data over the Asymmetrically encrypted connection to arrive at a shared secret that can be used for the Symmetrically Encrypted connection.
  • AES, Blowfish, 3DES, CAST128, and Arcfour are examples of algorithms that need a shared secret.

Asymmetrical Encryption

To send information in a single direction, two keys are needed.

• Public
  • Can be freely shared with anyone.
  • The private key cannot be derived from the public key.
  • The public key can be used to encrypt messages that can only be decrypted by the private key.
  • This is a one-way ability. The public key cannot decrypt the messages it encrypts.
• Private
  • The private key is the only component capable of decrypting messages that were encrypted using the public key.

SSH utilizes asymmetric encryption in a few different places:

• When it is setting up the symmetrical encryption between the client and the server.
• When challenging the user. Is this user in my ~/.ssh/authorized_keys file?

Hashing

Hash-Based Message Authentication Codes (HMAC)

• The MAC is calculated from the symmetric shared secret, the packet sequence number of the message, and the actual message itself.
• The MAC is sent outside of the symmetrically encrypted area of the message.
• It can be used at the client side to verify that the message was not tampered with.

Overview

• Client-Server
• The server listens on (22) a designated port.
• The server is responsible for:
  • Negotiating the symmetrically secure connection.
  • Authenticating the connecting party.
  • Creating that user’s environment.
• The client is responsible for:
  • The initial TCP Handshake
  • Negotiating for the secure connection.
  • Verifying that the server’s identity matches one in known_hosts
  • Providing credentials.

Stage Detail

Stage 1: Create the secure connection.

• The client initiates an TCP connection.
• The server responds with the protocol versions it supports.
• They agree on one.
• The server provides its public host key. The client can use this to see if they know/trust this host.
• To negotiate the symmetric encryption shared secret, the client and server use the Diffie-Hellman algorithm.
  • Both parties agree on a large prime number, the seed / public key.
  • Both parties agree on an encryption generator (likely AES)
  • Each party then finds another prime number. This is a ‘private key’ for the duration of this interaction.
  • The private, the public seed, and the algorithm are used to generate a key which can be shared with the other party.
  • The recipient uses their private number, the other party’s public key (just exchanged), and the original shared prime to compute a shared secret.
  • This results in the same key.

Stage 2: Authenticate the user.

• Password Authentication (simple)
  • The server asks for this user’s password.
  • This can be sent plaintext because the channel is encrypted.
  • This is vulnerable to brute force attacks.
• SSH Key pairs
  • Asymmetric key pairs.
  • Negotiated via the already secure channel.
  • The client sends the ID of the keypair it would like to authenticate against to the server.
  • The server checks authorized_keys for this ID.
  • If the key is found, the server generates a random number and uses the public key to encrypt the number.
  • The server sends this encrypted message to the client.
  • If the client can, it decrypts this message.
  • The client combines the decrypted number with the shared session key and MD5 hashes this value.
  • The client sends this hash to the server.
  • The server has calculated this answer independently. If the the values agree, the server knows the client has said private key, and the client is authenticated.