SSH Connection Refused on macOS: Causes and Quick Fixes

What Does the SSH Connection Refused Error Mean

The SSH Connection Refused error occurs when an SSH client attempts to establish a connection with a server, but the server (or an intermediate network device) actively rejects the connection on the specified port (default 22). The full error message typically looks like this:

ssh: connect to host example.com port 22: Connection refused

This means the SYN packet sent to port 22 received an RST (reset) response or no response at all, and the connection cannot be established. The error occurs at the TCP connection establishment stage, before the SSH handshake begins. On macOS, this is commonly encountered when trying to connect to a remote server, a local virtual machine, or even your own computer if the SSH server is not configured.

Common Causes

The Connection Refused error can be triggered by several specific issues:

1. SSH server is not running on the target host — the sshd service is inactive, so port 22 is closed and not responding to requests.
2. Firewall is blocking port 22 — a firewall on the server or client (for outbound connections) is dropping packets destined for port 22.
3. SSH server is configured on a non-standard port — if the server uses a port other than 22 (e.g., 2222) and the client attempts to connect to 22, the connection will be refused.
4. Network issues — the host is unreachable, routing is misconfigured, or there are problems with the network interface (e.g., Wi-Fi is disconnected).
5. Access restrictions in SSH configuration — hosts.allow/hosts.deny files or sshd_config settings (e.g., AllowUsers or DenyUsers) may be prohibiting connections from your IP address or user.
6. Port 22 is occupied by another process — another service (e.g., a web server) is listening on port 22 on the server, causing a conflict.
7. Server IP address has changed or is unavailable — if you are using a domain, the DNS record may be outdated, or the server may be temporarily offline.
8. Server connection limit has been reached — if the maximum number of simultaneous SSH connections has been attained, new connection attempts will be rejected.

Troubleshooting Steps

Step 1: Verify and Start the SSH Server on the Target Host

If you have access to the target server (e.g., via console, KVM, or hosting control panel), ensure the SSH service is running. For macOS and Linux servers:

On the server (Linux with systemd):

1. Check the service status:

   sudo systemctl status sshd
   

   If the service is inactive, start it:

   sudo systemctl start sshd
   sudo systemctl enable sshd   # To enable auto-start on boot
   

On the server (macOS):

1. Check the status of Remote Login (SSH):

   sudo systemsetup -getremotelogin
   

   
   If the output is Off, enable SSH:

   sudo systemsetup -setremotelogin on
   

   
   Alternatively, use launchctl:

   sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
   

2. Confirm port 22 is being listened on:

   sudo lsof -i :22
   

   
   The output should show the sshd process (e.g., sshd 1234 root 3u IPv4 0x... TCP *:ssh (LISTEN)).
3. If the service fails to start, check the logs for errors:

   sudo tail -f /var/log/system.log   # macOS
   sudo journalctl -u sshd -f         # Linux systemd
   

   
   Common errors: incorrect permissions on configuration files, port conflicts.

If the server is your own Mac: perform the same steps on your computer to ensure the local SSH server is active (e.g., for testing connections to localhost).

Step 2: Check the Firewall on Server and Client

A firewall can block inbound or outbound connections on port 22. Check the settings on both the server and, if necessary, the client.

On the server (macOS):

1. Open System Preferences → Security & Privacy → Firewall → Firewall Options.
2. Ensure sshd or Remote Login (SSH) is in the list of allowed applications. If not, add it manually:

   sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/sbin/sshd
   sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/sbin/sshd
   

3. Also verify if the firewall is enabled:

   sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
   

   1 means enabled, 0 means disabled.

On the server (Linux):

sudo iptables -L -n | grep 22

Or for nftables:

sudo nft list ruleset | grep 22

Allow the port if needed (example for iptables):

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables-save | sudo tee /etc/iptables/rules.v4

On the client (your Mac): rarely, a firewall might block outbound connections. Check settings in System Preferences → Security & Privacy → Firewall. By default, outbound connections are allowed, but if strict rules are enabled, ensure Terminal (or your SSH client) is permitted to make outbound connections.

Step 3: Check Network Connectivity and Host Accuracy

Ensure the host is reachable and the port is open before blaming SSH.

1. Ping the host:

   ping example.com
   

   
   If the ping fails (100% packet loss), there is a network issue or the host is unreachable. Check your internet connection and DNS accuracy.
2. Test port 22 accessibility: Use nc (netcat) or telnet to test the connection:

   nc -zv example.com 22
   

   
   Or:

   telnet example.com 22
   

   
   Possible outcomes:
   • Connection refused — port is closed or filtered.
   • Connection timed out — packets are being dropped (possibly by a firewall without response).
   • Connected to example.com — port is open; the issue may lie in SSH configuration.
3. Verify host and port correctness: check that you are using the correct hostname or IP address. If the SSH server uses a non-standard port (e.g., 2222), specify it with the -p flag:

   ssh -p 2222 user@example.com
   

4. Check routing: if the server is on a local network, ensure you are in the same subnet and there are no IP conflicts.

Step 4: Review SSH Server Configuration

If you have access to the server (e.g., via a management console), check the sshd_config file for errors or restrictions.

1. Open the file:

   sudo nano /etc/ssh/sshd_config
   

   
   Or use vi/vim.
2. Ensure key parameters are correctly set:
   • Port 22 (or the port you are using). If the port is changed, the client must connect to that port.
   • ListenAddress 0.0.0.0 (for IPv4) or ListenAddress :: (for IPv6) — to listen on all interfaces. If a specific IP is set, connections from other addresses will be refused.
   • PermitRootLogin — if you are trying to connect as root, ensure it is allowed (yes or prohibit-password).
   • AllowUsers or DenyUsers — check that your user is not denied.
   • PasswordAuthentication — if using a password, this should be yes (or no for key-based auth).
   • MaxAuthTries — if authentication attempts are exhausted, new connections may be rejected.
3. After making changes, restart the SSH server:

   sudo systemctl restart sshd   # Linux
   sudo launchctl stop com.openssh.sshd && sudo launchctl start com.openssh.sshd   # macOS
   

4. Check the logs for errors during restart:

   sudo tail -f /var/log/auth.log   # Linux (Debian/Ubuntu)
   sudo tail -f /var/log/secure     # Linux (RHEL/CentOS)
   sudo tail -f /var/log/system.log   # macOS
   

   
   Look for lines containing sshd and error or failed.

Step 5: Check hosts.allow and hosts.deny Files

Some systems use TCP wrappers (with hosts.allow and hosts.deny files) to restrict service access.

1. Check the file contents:

   cat /etc/hosts.allow
   cat /etc/hosts.deny
   

   
   Typically, to allow everyone, hosts.allow should contain:

   sshd: ALL
   

   
   If hosts.deny has a line ALL: ALL, it may override permissions. Processing order: hosts.allow first, then hosts.deny.
2. If there are restrictions, add your IP address or network to hosts.allow:

   sshd: 192.168.1.0/24
   sshd: 203.0.113.5
   

3. After changes, restart the SSH server (see Step 4).

Prevention

To avoid recurring SSH Connection Refused errors, follow these best practices:

• Keep your system and OpenSSH updated regularly — this ensures security and patches known vulnerabilities. On macOS, use System Preferences → Software Update.
• Configure your firewall properly — allow only necessary ports and IP addresses for SSH. Use tools like fail2ban (on Linux) to protect against brute-force attacks, but on macOS ensure the built-in firewall isn't blocking legitimate connections.
• Monitor SSH logs — regularly check /var/log/auth.log (Linux) or system.log (macOS) for suspicious activity or errors. Consider setting up alerts.
• Use SSH keys instead of passwords — this is more secure and convenient. Generate a key with ssh-keygen -t ed25519 and add the public key to ~/.ssh/authorized_keys on the server. Disable password authentication (PasswordAuthentication no in sshd_config) if possible.
• Change the default port 22 — this reduces automated attack volume. However, ensure the new port is open in the firewall and document the change. Connect using the -p flag.
• Regularly verify server availability — use simple monitoring scripts (e.g., nc -z in cron) or services like UptimeRobot to quickly detect SSH service outages.
• Document configuration changes — if you modify SSH settings (port, user access), record them in a separate file or version control system for easy rollback if issues arise.
• Test changes in an isolated environment — before applying configuration changes to a production server, test them on a test host.
• Restrict access by IP — if the server is only used from specific networks, configure the firewall or sshd_config (via Match blocks) to allow only trusted IP addresses.