EX200 Deploy, configure, and maintain systems Practice Question
Exhibit
$ journalctl -u sshd.service -p err --since yesterday -- Logs begin at Mon 2024-03-25 10:00:00 EDT, end at Tue 2024-03-26 09:30:00 EDT Mar 25 14:22:31 server sshd[1234]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.100 user=root Mar 25 14:22:35 server sshd[1234]: Failed password for root from 192.168.1.100 port 22 ssh2 Mar 25 14:23:01 server sshd[1235]: fatal: Unable to negotiate with 192.168.1.101 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss Mar 25 14:23:02 server sshd[1235]: Connection closed by 192.168.1.101
Refer to the exhibit. An administrator sees that a user from 192.168.1.101 cannot connect to the SSH server. Based on the log, what is the most probable cause?
⚠ Common exam trap
The RHCSA exam often tests the distinction between authentication failures (e.g., wrong password or key) and key exchange failures (e.g., unsupported host key algorithm), leading candidates to mistakenly blame firewall rules or service status when the log clearly points to a cryptographic algorithm mismatch.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The client's host key type is not supported by the server
The log shows 'no matching host key type found. Their offer: ssh-rsa'. This indicates the client offered an ssh-rsa host key, but the server's configuration (likely via the `HostKeyAlgorithms` directive in `/etc/ssh/sshd_config`) does not include ssh-rsa. In modern OpenSSH (e.g., RHEL 8/9), ssh-rsa is often disabled by default due to its reliance on SHA-1, which is considered weak. The server requires a different host key type (e.g., rsa-sha2-256, rsa-sha2-512, or ecdsa-sha2-nistp256), causing the connection to fail before authentication even begins.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The client's host key type is not supported by the server
Why this is correct
The SSH handshake fails during algorithm negotiation because the server's list of acceptable host key algorithms (as sent in its SSH_MSG_KEXINIT) does not include the type the client offers, such as ssh-rsa or ssh-ed25519. This produces a 'no matching host key type' error before any authentication, which is exactly the negotiation failure recorded in the log. The server does not reject the client's credentials or IP; it cannot even complete the transport layer handshake.
- ✗
The server's firewall is blocking the connection
Why it's wrong here
A firewall block would prevent the TCP handshake from completing, causing the SSH client to hang until timeout or receive 'Connection refused' if the port is closed, not an SSH protocol-level error. Since the log contains sshd's own messages about the failed key exchange, the client's packets reached the sshd process on TCP port 22, proving no firewall dropped or rejected the connection.
- ✗
The SSH service is not running
Why it's wrong here
If the SSH service were not running, there would be no sshd process to write log entries, and the client would immediately get 'Connection refused' because nothing is listening on port 22. The exhibit explicitly shows sshd logging the negotiation failure, meaning the service is active and accepting TCP connections. An inactive or crashed sshd cannot generate a host key algorithm mismatch.
- ✗
The client's IP is blacklisted
Why it's wrong here
An IP blacklist implemented via /etc/hosts.deny, iptables, or fail2ban would cause the connection to be dropped or refused before SSH negotiation begins, typically logging a separate 'denied' or 'blocked' message. The log in question shows the client successfully reached sshd and exchanged KEXINIT messages, so the source IP was not blacklisted. Blacklisting would prevent any SSH banner or algorithm negotiation from appearing.
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
Go deeper
Related to this question
About these practice questions
One of 127 original EX200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX200 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX200 exam.