Why a Reverse SSH Proxy Listener Is Reachable Only on the Server
Check the remote listener’s bind address and GatewayPorts mode before changing the proxy protocol or credentials.
A remote forward can work from the SSH server while refusing connections from another machine because it listens only on loopback. Check the actual listener address first.
Server-side GatewayPorts | Remote-forward binding |
|---|---|
no, the default | Restricts listeners to loopback |
yes | Forces wildcard binding |
clientspecified | Allows the client to request a particular bind address |
For a listener intended on one controlled interface, the server can use:
GatewayPorts clientspecifiedThe client then requests an appropriate address in its -R specification. That address must exist on the remote machine, and other forwarding restrictions still apply. Client-side -g is not an interchangeable control for this direction.
Three permissions remain distinct: SSH authorization to create the forward, network access to its listener, and the HTTP or SOCKS service's own access policy. An SSH login authenticates the tunnel creator; it does not authenticate every later caller of a shared listener or add a SOCKS password challenge.
If a remote caller still cannot connect, inspect the bind address, server forwarding restrictions and firewall path in that order. Once TCP reaches the listener, a failed proxy handshake is a later problem.