7

Trying to etablish remote ssh port forwarding:

On my remote host, /etc/ssh/sshd_config

GatewayPorts clientspecified

On my local computer:

ssh -g -R 1234:0.0.0.0:8000 me@my-remote-host

With debug, we can read:

debug1: Authentication succeeded (publickey). Authenticated to s1.bux.fr ([178.32.223.76]:22). debug1: Remote connections from LOCALHOST:1234 forwarded to local address 0.0.0.0:8000 debug2: fd 3 setting TCP_NODELAY debug1: Requesting [email protected] debug1: Entering interactive session. debug1: remote forward success for: listen 1234, connect 0.0.0.0:8000 debug1: All remote forwarding requests processed

On remote host, we can contact 1234 port (WSGIServer/0.2 CPython/3.4.3 is the local machine 8000 port):

# http :1234 HTTP/1.0 302 Found Content-Type: text/html; charset=utf-8 Date: Wed, 19 Oct 2016 13:26:00 GMT Location: /accounts/login/ Server: WSGIServer/0.2 CPython/3.4.3 Vary: Cookie X-Frame-Options: SAMEORIGIN

We can view opened port:

# netstat -tupln | grep 1234 tcp 0 0 127.0.0.1:1234 0.0.0.0:* LISTEN 14460/1 tcp6 0 0 ::1:1234 :::* LISTEN 14460/1

But, from another machine in world, i'm unable to contact my-remote-host:1324:

# http my-remote-host:1234 http: error: ConnectionError: HTTPConnectionPool(host='my-remote-host', port=1234): Max retries exceeded with url: / (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0xb6b2fbec>: Failed to establish a new connection: [Errno 111] Connection refused',)) while doing GET request to URL: http://my-remote-host:1234/

There is no firewall on my-remote-host:

# iptables -L [sudo] password for bux: Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-sshd tcp -- anywhere anywhere multiport dports ssh fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain fail2ban-ssh (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-sshd (1 references) target prot opt source destination RETURN all -- anywhere anywhere

How found where it's blocking ?

Improve this question

3 Answers 3

Reset to default
10 
tcp 0 0 127.0.0.1:1234 0.0.0.0:* LISTEN 14460/1

Problem can be very well seen in the output of netstat. Your remote machine is listening on 127.0.0.1:1234, which is only available for local connection from that machine.

For ssh -g (gateway option) to work, you must specify wildcard address or some interface address reachable from the foreign client like: 

ssh -g -R 0.0.0.0:1234:0.0.0.0:8000 me@my-remote-host
Improve this answer
5

Solution found is https://superuser.com/questions/588591/how-to-make-ssh-tunnel-open-to-public:

We have to set bind address like this:

ssh -R 0.0.0.0:1234:0.0.0.0:8000 me@my-remote-host
Improve this answer
2
  • Surprise - there is indeed no "-g" option needed, it worked from the moment on I used the bind address 0.0.0.0 - thanks Commented Jun 2, 2017 at 17:06
  • +1 to this answer, as it works to on Putty SSH client for Windows. Commented Aug 15, 2022 at 17:25
0

From man ssh:

 -g Allows remote hosts to connect to local forwarded ports. If used on a multiplexed connection, then this option must be specified on the master process.

-L for local forwarding, and -R for remote forwarding. -g doesn't apply for remote.

Improve this answer
6
  • Command executed without -g parameter produce same behaviour as presented in question. Commented Oct 19, 2016 at 13:41
  • Of course. The manual clearly says that -g doesn't have any effect when using -R. Commented Oct 19, 2016 at 13:43
  • Your response is off-topic. You should simply comment my question. Commented Oct 19, 2016 at 13:52
  • There is no any blocking at all. You listen on localhost (# netstat -tupln | grep 1234 tcp 0 0 127.0.0.1:1234) and this is the reason why any other incoming connections get refused. ssh has no option for what you wanna do. Look for other solution! Commented Oct 19, 2016 at 13:55
  • I use this same command at work, on other remote host with no troubles. So there is an different configuration on the current remote host. Commented Oct 19, 2016 at 13:58

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.