When working in locked-down environments where only inbound SSH is permitted through VPN (typically via port 22), administrators often need web access for package management while maintaining security compliance. The key constraints we're addressing:

• DMZ firewall blocks all outbound HTTP/HTTPS traffic
• No additional services can be installed on target servers
• Existing SSH access must be leveraged for tunneling

The standard ssh -D SOCKS proxy creates a local proxy that routes client traffic through the server. What we need is the inverse - routing server traffic through the client. Here's why the default approach fails:

# Standard SOCKS proxy (won't solve our problem)
ssh -D 1080 user@restricted-server
# This only allows YOUR local apps to use the server as proxy

We'll create a two-step tunnel that establishes:

1. Local SOCKS proxy on your workstation
2. Reverse tunnel that makes it available to the restricted server

# On your local machine (with internet access):
ssh -R 1080:localhost:1080 user@restricted-server

# On the restricted server (after SSH connection established):
export https_proxy="socks5://localhost:1080"
yum update --enablerepo=updates

For reliable package management during admin sessions:

# ~/.ssh/config entry
Host restricted-server
  HostName 192.168.1.100
  User admin
  RemoteForward 1080 localhost:1080
  ServerAliveInterval 60
  ExitOnForwardFailure yes

# Connect using:
ssh -fNT -D 1080 restricted-server

For Debian/Ubuntu systems, configure APT to use the tunnel:

# /etc/apt/apt.conf.d/30proxy
Acquire::http::Proxy "socks5h://localhost:1080";
Acquire::https::Proxy "socks5h://localhost:1080";

• Verify tunnel with curl --socks5 localhost:1080 ifconfig.co on server
• Check netstat -tulnp | grep 1080 for port availability
• Use -v flag with SSH for connection debugging
• Consider autossh for automatically reestablished connections

Many sysadmins face situations where servers in DMZs or restricted networks only allow inbound SSH connections (typically through a VPN), while outbound HTTP/HTTPS traffic is completely blocked. This makes it impossible to perform routine maintenance tasks like:

• Running yum update or apt-get upgrade
• Downloading software packages
• Accessing external documentation

The classic ssh -D SOCKS proxy only works from your local machine to the remote server. What we need is the reverse - tunneling web requests from the restricted server through our local machine.

Here's how to create a bidirectional tunnel:

# On your local machine (with internet access):
ssh -R 9999:localhost:1080 user@restricted-server

# On the restricted server:
export http_proxy="socks5://localhost:9999"
export https_proxy="socks5://localhost:9999"

# Now test it:
curl --proxy socks5://localhost:9999 https://example.com

For longer sessions, use autossh to maintain the connection:

autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" \
-N -R 9999:localhost:1080 user@restricted-server

For yum:

echo "proxy=socks5://localhost:9999" >> /etc/yum.conf

For apt:

echo 'Acquire::http::Proxy "socks5h://localhost:9999";' > /etc/apt/apt.conf.d/30proxy
echo 'Acquire::https::Proxy "socks5h://localhost:9999";' >> /etc/apt/apt.conf.d/30proxy

Add this to your ~/.ssh/config:

Host restricted-server-tunnel
    HostName restricted-server.example.com
    User yourusername
    RemoteForward 9999 localhost:1080
    ServerAliveInterval 30
    ExitOnForwardFailure yes

• Check GatewayPorts setting in /etc/ssh/sshd_config on the remote server
• Verify the tunnel with netstat -tulnp | grep 9999
• Use -v flag with SSH for debugging connection issues