SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  1: Client initiates SSH connection, 2: Server sends host key, 3: Diffie-Hellman key exchange, 4: Encryption established

  Why this is correct

  The SSH handshake always starts with the client opening a TCP connection and exchanging protocol version banners. After this initial handshake, the server sends its host key so the client can verify the server's identity before any key exchange parameters are trusted. Next, the Diffie-Hellman key exchange allows both peers to independently compute a shared secret without ever transmitting it. Only then do both sides activate symmetric encryption using session keys derived from that shared secret.

• ✗

  1: Client initiates, 2: Diffie-Hellman key exchange, 3: Server sends host key, 4: Encryption established

  Why it's wrong here

  This order is wrong because the server's host key must be sent before the Diffie-Hellman key exchange so the client can verify the server's identity; without it, the client cannot trust the key exchange parameters.

• ✗

  1: Server sends host key, 2: Client initiates, 3: Diffie-Hellman key exchange, 4: Encryption established

  Why it's wrong here

  This sequence is impossible because the server can only send its host key after the client has established a TCP connection and initiated the SSH protocol exchange. In practice, the server remains passive until it receives the client's version string and algorithm negotiation; only then will it present its host key within the key exchange reply. Without a client-initiated connection, there is no channel on which the server can transmit anything, so this ordering violates the client-server relationship.

• ✗

  1: Client initiates, 2: Server sends host key, 3: Encryption established, 4: Diffie-Hellman key exchange

  Why it's wrong here

  Placing encryption before the Diffie-Hellman key exchange is technically backwards because symmetric encryption requires an agreed-upon session key, which is precisely the output of the DH computation. During the actual SSH handshake, the DH exchange yields a shared secret that is then run through a key derivation function to produce the encryption keys; only after both sides verify the same secret via SSH_MSG_NEWKEYS does encrypted communication begin. Establishing encryption earlier would leave no shared key to encrypt with.

Go deeper

Related to this question