An SSH timeout happens before password validation. The first suspects are therefore the target address, port, route, firewall and sshd listening state, not the username or password. “Connection refused” and “connection timed out” represent different failure layers and require different actions.
The same error screen can originate from different services. Separate network reachability, service state, firewall policy and authentication before changing anything.
The client sends traffic but receives no permitted response; prioritize network and firewall checks.
The host is reachable, but no service listens on the port or a REJECT rule is active.
TCP and the SSH handshake succeeded; inspect the account, key or password.
Source-address filtering, corporate egress policy or a different CGNAT path is involved.
Instead of disabling the entire protection stack, prove which rule blocks access and change only the required scope.
The server may listen on 3458 while the client still targets port 22 or an old value.
An sshd_config change cannot bypass CSF TCP_IN or a closed provider firewall.
The service may still use the old configuration or fail validation.
Successful access from a different connection strongly supports an address-specific block.
Back up the current configuration, validate syntax and keep a second administration session open before every service or firewall change.
Check address, port, user and proxy or tunnel fields; do not confuse a tunneling notice with TCP failure.
Use nc or Test-NetConnection from the same client network.
Inspect the real sshd port, service state and recent journal messages.
Do not restart sshd unless sshd -t succeeds, and keep the working session open.
Check the port and source in CSF, then inspect cPHulk and Fail2ban jail state.
Open a second public-key session successfully before ending the current root connection.
Replace example IP addresses, ports and paths with your own values. Review command output before moving to the next step.
nc -vz -w 5 203.0.113.20 3458 ssh -vvv -p 3458 [email protected]
ss -lntp | grep sshd sshd -T | grep -E '^(port|listenaddress|passwordauthentication|pubkeyauthentication)' systemctl status sshd --no-pager -l
/usr/sbin/sshd -t && /usr/local/cpanel/scripts/restartsrv_sshd journalctl -u sshd --since '-30 minutes' --no-pager | tail -n 100
csf -g 3458 csf -g 203.0.113.10 fail2ban-client status 2>/dev/null || true whmapi1 --output=jsonpretty cphulk_status
A wrong firewall, SSH or login-protection rule can make the server unreachable. Do not close management ports without KVM, VNC or provider console access.
No. A timeout usually occurs before the SSH authentication phase, at the TCP, routing or firewall layer.
It can reduce automated noise, but it does not replace strong key authentication, firewall restriction, root policy and updates.
Run sshd -t and keep the current session open until a second connection succeeds.
cPanel documentation states that cPHulk does not affect public-key authentication.
Custom ports, sshd_config, service restart and recovery procedure.
Required inbound and outbound network permissions for SSH and cPanel services.
Source-address allow, reject and drop rules for the sshd service.
SSH monitoring behavior and the public-key authentication exception.
Supported service restart methods through WHM and the command line.
The correct security method is not to disable protection, but to measure the network, service and rule path and apply the narrowest safe change.