This error occurs during SSH port forwarding (tunneling) when the target service is not running, listening on the wrong port, or blocked by a firewall. The SSH connection succeeds, but the forwarded connection to the remote service fails.
The "channel open failed: connect failed: Connection refused" error happens specifically during SSH port forwarding operations. Unlike a general SSH connection refused error, this occurs after your SSH connection to the server is established. The SSH client has successfully connected to the remote SSH server, but when it attempts to forward a connection to a service on the remote host (or through to another destination), that service is not accepting connections. This typically means the target service is not running, listening on a different port, or the firewall is blocking the connection.
SSH into the remote server directly and check if the target service is active.
# Check if service is running (e.g., MySQL on port 3306)
ssh user@remote-host
netstat -tlnp | grep <port>
# or using ss
ss -tlnp | grep <port>
# Or check service status directly
sudo systemctl status mysql # or your service name
sudo systemctl status postgresql
sudo systemctl status redis-serverIf the service is not running, start it:
sudo systemctl start mysql
sudo systemctl start postgresqlVerify that your SSH forwarding command uses the correct port where the service is listening.
# Example: Forwarding MySQL (3306) from remote host
ssh -L 3306:localhost:3306 user@remote-host
# Example: Forwarding PostgreSQL (5432)
ssh -L 5432:localhost:5432 user@remote-host
# Example: Forwarding web server (8080)
ssh -L 8080:localhost:8080 user@remote-hostVerify the remote service is actually listening on that port:
ssh user@remote-host
netstat -tlnp | grep LISTENLook for the port you're trying to forward and note which service is bound to it.
From the remote host, test if you can reach the target service locally:
ssh user@remote-host
# Test with curl (for HTTP services)
curl localhost:8080
# Test with nc (netcat) for any service
nc -zv localhost 3306
# Test with telnet
telnet localhost 3306
# Test with psql (PostgreSQL)
psql -h localhost -U postgresIf these commands fail on the remote host itself, the service is not running or not listening on that port.
The remote firewall might be blocking connections to the service port:
# Check iptables rules
sudo iptables -L -n
# Check firewalld (RHEL/CentOS)
sudo firewall-cmd --list-all
# Check UFW (Ubuntu/Debian)
sudo ufw statusIf the port is blocked, add a firewall rule to allow it (only for internal traffic if possible):
# UFW example - allow MySQL from localhost
sudo ufw allow 3306/tcp
# iptables example
sudo iptables -A INPUT -p tcp -d 127.0.0.1 --dport 3306 -j ACCEPT
# firewalld example
sudo firewall-cmd --permanent --add-port=3306/tcp
sudo firewall-cmd --reloadUse verbose mode to see exactly where the connection fails:
# Single verbose flag - basic debugging
ssh -v -L 3306:localhost:3306 user@remote-host
# Double verbose flag - more detailed
ssh -vv -L 3306:localhost:3306 user@remote-host
# Triple verbose flag - maximum detail
ssh -vvv -L 3306:localhost:3306 user@remote-hostLook for messages like:
- "Connection refused" - service not running or wrong port
- "Entering interactive session" - tunnel established successfully
- "channel X: open failed" - the actual error point
If the service is only bound to localhost/127.0.0.1 and you need to access it from another interface:
# Edit the service configuration
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
# Look for: bind-address = 127.0.0.1
# Change to: bind-address = 0.0.0.0
# Or specify multiple addresses
# After changes, restart the service
sudo systemctl restart mysqlAlternatively, use SSH tunneling to localhost specifically:
# The middle parameter should be localhost, not the hostname
ssh -L 3306:localhost:3306 user@remote-hostSSH port forwarding operates in two phases: first establishing the SSH connection to the remote server, then creating a tunnel to the target service. This error indicates phase two is failing. The distinction is important because it means your authentication and network connectivity are working—the problem is specifically with the target service accessibility. When using remote port forwarding (ssh -R), ensure the remote host has GatewayPorts enabled in sshd_config if you need to access the forwarded port from other hosts. For security, services should be bound to localhost only, requiring SSH tunneling for remote access rather than exposing them directly.
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