When setting up a SOCKS proxy tunnel between two CentOS machines using ssh -D 1080 user@8.8.8.8, you might encounter the frustrating "bind: Cannot assign requested address" error despite proper authentication. Let's dissect this peculiar scenario where:

• The tunnel appears to establish (visible in netstat -lnp)
• Client applications attempt to use the proxy without immediate failure
• Identical Putty configurations work in Windows VM but fail on native Linux

The critical clues emerge from SSH's verbose output:

debug1: Local forwarding listening on 127.0.0.1 port 1080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 1080.
bind: Cannot assign requested address

This reveals the tunnel attempts dual-stack binding (IPv4 and IPv6) but fails on the IPv6 portion (::1).

Your system likely has:

1. Functional IPv4 loopback (127.0.0.1)
2. Misconfigured or disabled IPv6 stack

Verify with:

ip -6 addr show lo
sysctl net.ipv6.conf.all.disable_ipv6

Option 1: Force IPv4 binding

ssh -D 127.0.0.1:1080 -o AddressFamily=inet user@8.8.8.8

Option 2: Fix IPv6 configuration

# Enable IPv6 if disabled
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=0

Option 3: Modify SSH client config

# Add to ~/.ssh/config
Host *
    AddressFamily inet

The Windows VM success vs. native Linux failure occurs because:

• Windows Putty defaults to IPv4-only operation
• Linux OpenSSH attempts dual-stack binding
• Linux Putty may inherit system IPv6 configuration

After applying any solution, test with:

curl --socks5 127.0.0.1:1080 https://ifconfig.co

For persistent configurations, add to /etc/ssh/ssh_config.d/99-force-ipv4.conf:

AddressFamily inet

---

When setting up an SSH SOCKS proxy using ssh -D, encountering the "bind: Cannot assign requested address" error can be particularly frustrating, especially when the port appears available and basic connectivity works. Let's examine this issue in depth.

The debug output reveals a critical detail:

debug1: Local forwarding listening on 127.0.0.1 port 1080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 1080.
bind: Cannot assign requested address

This shows SSH is attempting to bind to both IPv4 (127.0.0.1) and IPv6 (::1) addresses, but failing on the IPv6 binding.

First, verify your system's IPv6 configuration:

cat /proc/sys/net/ipv6/conf/all/disable_ipv6

If this returns 1, your system has IPv6 disabled. Modern SSH clients attempt dual-stack binding by default.

Here are three approaches that worked for different users experiencing similar issues:

Option 1: Force IPv4 binding explicitly

ssh -D 127.0.0.1:1080 user@8.8.8.8

Option 2: Modify the SSH client configuration

# Add to ~/.ssh/config
Host *
    AddressFamily inet

Option 3: System-wide IPv6 disable (if appropriate for your environment)

echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
sysctl -p

The observed behavior where Putty works in Windows but not on Linux makes sense when considering:

• Windows Putty builds often have different default connection settings
• The Virtual Box environment might have different network stack configurations
• Native Linux Putty may inherit system-wide IPv6 settings

For persistent cases, enable verbose debugging:

ssh -vvv -D 1080 user@8.8.8.8

Check for these specific messages:

debug1: attempting to bind to [::1]:1080
debug1: bind [::1]:1080: Cannot assign requested address

While PermitTunnel yes in sshd_config is good for general tunneling, SOCKS proxies primarily depend on:

AllowTcpForwarding yes
GatewayPorts clientspecified

These settings control the core functionality needed for -D port forwarding.

Don't forget to check local firewall rules that might interfere with binding:

iptables -L -n
firewall-cmd --list-all

Particularly look for rules affecting the loopback interface or your specific port.