Understand ssh agent forwarding in 1 minute!

ssh agent forwarding

Key Concepts:
1. understand what is a key challenge
2. agent constructs response to remote server's key challenge without revealing the private key;
3. the "middleman" server's sshd daemon acts as agent and relays ssh authentication traffic between the client and destination hosts;


The difference between basic ssh connection and agent based ssh connection:

The very basic ssh connection is ssh client (instead of agent) uses private key to construct response for remote server's key challenge.

ssh agent forwarding means agent can verify a user's identity without revealing the private key to the remote host.
With agent, the ssh client passes the remote key challenge to the agent. The agent uses the private key to construct
a response key-challenge and sends it back to ssh process which sends it off to the remote sshd.


Example:

(assume ssh port 22 or whatever is opened on all servers)

A user shan on ipc4 has established ssh connection with server1 via agent.

with agent-forwarding, user shan@ipc4 has established ssh access to server1 with agent, now shan@ipc4 needs to access server2 which has his account's public key.

shan@ipc4 issues ssh connection request via agent-forwarding to server2 thru server1; the ssh client on server1 receives the key challenge from server2, it forwards that challenge to the
sshd daemon on the same machine acting as a key agent, server1's sshd relays the key challenge to the ipc4's ssh client
who sends the challenge to the agent on ipc4. ipc4's agent contructs the key response using the private key and sends back to
server1's sshd which acts as agent then sends back to server2.




What's key challenge

server:
encrypt (random number + public key) => key challenge --------> client

client:
decrypt (key challenge + private key) = challenge.txt, key response = MD5 hash ( challenge txt + session ID ) ----- server

server encrypts a large random number with the user's public key to create a key challenge then sends back to client.
the client must use user's private key to decrypt the key challenge.

Key response
When the agent receives the challenge, it decrypts it with the private key. If this key is the "other half" of the public key
on the server, the decryption will be successful, revealing the original random number generated by the server. Only the holder
of the private key could ever extract this random number, so this constitutes proof that the user is the holder of the private key.

The agent takes this random number, appends the SSH session ID (which varies from connection to connection), and creates an MD5
hash value of the resultant string: this result is sent back to the server as the key response.

The server computes the same MD5 hash (random number + session ID) and compares it with the key response from the agent: if they
match, the user must have been in possession of the private key, and access is granted. If not, the next key in the list (of any)
is tried in succession until a valid key is found, or no more authorized keys are available. At that point, access is denied.

Curiously, the actual random number is never exposed in the client/agent exchange - it's sent encrypted to the agent, and
included in an MD5 hash from the agent. It's likely that this is a security precaution designed to make it harder to characterize
the properties of the random number generator on the server by looking at the the client/agent exchange.

Reference: SSH The Definitive Guide (Chapter 6 - Key Management and Agents)