A financial firm requires all internal SSH connections to be encrypted with at least 256-bit ciphers. An administrator is configuring the SSH server. Which configuration line should be added to /etc/ssh/sshd_config?
Restricting the server to `aes256-ctr` satisfies the 256-bit minimum by offering only that cipher during negotiation. Unlike `aes128-ctr`, it meets the stated strength floor, and unlike broad lists such as `aes256-ctr,aes128-ctr`, it cannot silently downgrade to a weaker algorithm.
Why this answer
The Ciphers directive in sshd_config explicitly controls the symmetric encryption algorithms used to encrypt SSH session data. The cipher aes256-ctr provides 256-bit encryption, meeting the firm's requirement for at least 256-bit ciphers. Other directives like MACs, KexAlgorithms, or HostKeyAlgorithms do not directly set the encryption cipher strength.
Exam trap
The trap here is that candidates confuse MACs, KexAlgorithms, or HostKeyAlgorithms with encryption ciphers, assuming any directive with '256' or 'sha256' implies 256-bit encryption, when only the Ciphers directive controls the symmetric encryption algorithm strength.
How to eliminate wrong answers
Option A is wrong because MACs (Message Authentication Codes) specify integrity-check algorithms like hmac-sha2-256, not encryption ciphers; they ensure data authenticity, not confidentiality. Option B is wrong because KexAlgorithms define key exchange methods (e.g., diffie-hellman-group-exchange-sha256) that negotiate session keys, but they do not determine the symmetric cipher used for encrypting the actual data stream. Option D is wrong because HostKeyAlgorithms specify which host key types (e.g., ssh-rsa) are accepted for server authentication, not the encryption cipher for the session.