The SSH daemon (sshd) is rejecting incoming connections from a specific hostname or IP address. This typically indicates TCP wrapper restrictions, firewall rules, or service misconfiguration preventing client access.
When sshd logs 'refused connect from hostname', it means the SSH server is actively rejecting the connection attempt before authentication occurs. This is different from a timeout or port closure. The refusal usually originates from TCP Wrappers (hosts.allow/hosts.deny files), which act as an additional access control layer on Linux systems. The SSH daemon checks these rules first, and if the connecting IP is explicitly denied or not explicitly allowed, the connection is refused. This message can also indicate that sshd itself encountered an error or is misconfigured.
First, verify that sshd is properly running and listening:
sudo systemctl status sshdIf the status shows 'active (running)', restart it:
sudo systemctl restart sshdThen immediately test your connection again. Sometimes sshd can appear to be running but has a stale state.
TCP Wrappers is a common cause of 'refused connect' messages. Check both configuration files:
sudo cat /etc/hosts.deny
sudo cat /etc/hosts.allowLook for any lines containing 'sshd' or 'ALL'. If you see sshd: ALL in hosts.deny, that's blocking all SSH connections. Remove or comment out such lines.
To explicitly allow SSH from your client IP, add to /etc/hosts.allow:
sudo echo 'sshd: 192.168.1.100' >> /etc/hosts.allowReplace 192.168.1.100 with your actual client IP address.
Identify what IP address or hostname the client is connecting from. Check the server logs:
sudo tail -f /var/log/auth.logOr on some systems:
sudo tail -f /var/log/secureLook for the 'refused connect from' line. Note the IP address shown. This is the address you need to allow in TCP Wrappers or firewall rules.
Verify that your firewall isn't blocking port 22:
sudo iptables -L -n | grep 22Or for firewalld:
sudo firewall-cmd --list-all | grep sshIf port 22 is blocked, allow it:
With iptables:
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPTWith firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadCheck your SSH daemon configuration for any explicit restrictions:
sudo cat /etc/ssh/sshd_config | grep -i 'allow\|deny'Look for directives like AllowUsers, DenyUsers, AllowGroups, or DenyGroups. If your user or IP is in a deny list, remove it or add yourself to the allow list.
Also check for Protocol, ListenAddress, or Port misconfigurations. If sshd is not listening on the correct interface or port, connections will be refused.
If you have Fail2Ban installed, it might be blocking your IP:
sudo fail2ban-client status sshdIf your IP is in the banned list, unban it:
sudo fail2ban-client set sshd unbanip 192.168.1.100Replace 192.168.1.100 with your actual IP address.
Once changes are made, test with verbose SSH output to confirm the connection:
ssh -vvv user@hostnameThis will show detailed logs of where the connection is failing. Look for 'refused' messages and use them to identify which component (TCP Wrappers, firewall, sshd config) is causing the rejection.
TCP Wrappers (libwrap) is a legacy access control mechanism that some systems still use. To check if sshd was compiled with TCP wrapper support, run: ldd /usr/sbin/sshd | grep libwrap. If libwrap is listed, TCP Wrappers rules are active. On modern systems using systemd and SELinux, ensure SELinux booleans like ssh_sysadm_login are set correctly. Some container environments (Docker, Kubernetes) may have network policies that appear as 'refused connect' errors at the sshd level. Additionally, some systems use tcpd directly as a wrapper around sshd in inetd.conf or systemd socket activation, which can also trigger this message. Always check system logs (journalctl, /var/log/auth.log) for the exact sshd error codes for more precise troubleshooting.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH