Detail and SSH connection
- 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.
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
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.
- 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
- Providing credentials.
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
- 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_keysfor 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.