SSH Review

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.