Questions: SSH: Secure Shell and Remote Access

Question 1

An attacker with a full packet capture of an SSH session between a client and server can read which of the following?

• A. Passwords and commands, but not the server's responses
• B. Nothing useful — the entire session payload is encrypted after the handshake
• C. Only the initial handshake, which is sent in plaintext before encryption is established
• D. Commands typed by the user but not files transferred via SCP

Answer: (B)

SSH encrypts the entire session — not just the password, but every command, every response, every file transferred, and every byte of data moving through the connection. After the transport layer negotiates encryption during the handshake, all subsequent traffic flows through an encrypted channel. An attacker with packet capture sees only ciphertext. This contrasts sharply with Telnet, which transmitted everything in plaintext. The common misconception (represented by option A) is that SSH only protects the password; in fact, the session channel provides end-to-end encryption for all traffic.

Question 2

How does SSH verify the identity of a server, and how does this differ from how TLS/HTTPS verifies a web server's identity?

• A. SSH uses certificate authorities (CAs) to sign host keys, just like TLS uses CAs for certificates
• B. SSH uses trust-on-first-use: the client accepts and stores the server's key on first connection, then verifies it matches on all subsequent connections
• C. SSH does not verify server identity — only the user's identity is verified
• D. SSH requires the server to present a certificate signed by a trusted CA before any connection is allowed

Answer: (B)

SSH uses a 'trust-on-first-use' (TOFU) model by default, not a certificate authority hierarchy. On first connection, SSH asks you to verify the server's host key fingerprint manually and stores it in `~/.ssh/known_hosts`. On subsequent connections, SSH checks the presented key against the stored copy — a mismatch triggers a warning (possible man-in-the-middle attack). TLS relies on CAs to pre-establish trust through signed certificates. SSH's TOFU model is simpler but shifts responsibility to the user to verify the fingerprint on first contact. Enterprise environments can configure SSH with CAs for automated trust, but TOFU is the default.

Question 3

SSH encrypts the authentication phase (login) but transmits commands and responses in plaintext once the session is established.

• T. True
• F. False

Answer: False

This is one of the most common misconceptions about SSH. The encryption established during the transport layer phase covers the entire session — authentication, commands, responses, and all data. The session channel is a continuously encrypted tunnel, not a single-use authentication wrapper. This is precisely why SSH replaced Telnet: Telnet encrypted nothing, while SSH encrypts everything. The only part that might be considered 'outside' the session channel is the initial key exchange negotiation itself, which uses public-key cryptography and does not require prior secrecy.

Question 4

In SSH key-based authentication, the private key never leaves the client machine — the server verifies the client's identity through a cryptographic challenge that the client answers using the private key.

• T. True
• F. False

Answer: True

This is the security advantage of key-based authentication over password authentication. The server knows the client's public key (stored in `~/.ssh/authorized_keys`). During authentication, the server sends a challenge encrypted with the client's public key. Only the holder of the matching private key can decrypt the challenge and produce the correct response. The private key is never transmitted — the server only sees the response. This is why key-based auth is immune to brute-force and password-guessing attacks, and why it is essential for automated systems that cannot type passwords interactively.

Question 5

Why is key-based SSH authentication strongly preferred over password authentication for automated systems and CI/CD pipelines?

Model answer: Automated systems cannot interactively type passwords, but they can use key files stored on disk. More importantly, key-based authentication is fundamentally more secure: the private key never travels over the network (only the response to a challenge does), so it cannot be captured by packet sniffing. Passwords, even over an encrypted channel, can be leaked through logs, brute-forced, or stolen from the server's authentication database. SSH keys with passphrases add a second factor. Additionally, fine-grained access control is easier with keys — a compromised key can be revoked by removing it from `authorized_keys` without changing credentials shared across systems.

For CI/CD pipelines specifically, the use of dedicated deploy keys (key pairs generated for a specific pipeline with minimal permissions) follows the principle of least privilege. If the pipeline is compromised, only that key needs to be revoked. With password authentication, shared credentials would need to be changed everywhere they are used. The combination of network security (key never transmitted), auditability (each key is a distinct identity), and revocability makes key-based auth the default for serious infrastructure automation.