Can I use other host instead of localhost for Destination Field in SSH Reverse Tunnel Port Forwarding?












1














I am using Putty to achieve SSH Reverse Tunnel Port Forwarding. Most of the tutorials are teaching me to forward remote port to localhost port. However, may I know is it make sense to input other host such as 192.168.1.132:8081 into the Destination field?



I have tried to do that. 192.168.1.132:8081 is a working web server with a contented page, but I got ERR_EMPTY_RESPONSE when I visit localhost:12345 (I set port 12345 as the source port) from the client device.





My Putty Configurations



Outgoing Proxy configuration:



Outgoing Proxy configuration



Tunneling config (the Dynamic one is for the Socks5 connection, please just ignore it; the R12345 one is the tunnel that I am playing with):



Tunneling config



The result that I try to access the tunnel from the Destination (SSH Server):



The result that I try to access the tunnel from the Destination (SSH Server)



Can anyone help me?





UPDATE 1



In the device that I am running SSH command, I am going out with via a proxy server. Is that affecting the reverse tunnel behavior?





UPDATE 2



I have tried to make the reverse tunnel from the http server directly. However, in the SSH server I can visit the website by http://localhost:12345. Attched setting and result at below.



Same, http server needed to go out via my office's http proxy too!



Create a reverse tunnel from http server



And then I can visit the http server from SSH server via localhost:12345










share|improve this question
























  • @KamilMaciorowski Sorry for undetailed question. I have updated the question with some image.
    – mannok
    Jan 19 '18 at 7:08






  • 1




    What happens when you browse 192.168.1.132:8081 from the SSH client? (with no SSH involved in this case at all). Do you see proper page?
    – Kamil Maciorowski
    Jan 19 '18 at 7:21










  • @KamilMaciorowski Sure, normal page, normal performance
    – mannok
    Jan 19 '18 at 7:34






  • 1




    Please read this. The HTTP server at 192.168.1.132:8081 may ignore requests destined to addresses other than 192.168.1.132. When you connect from the remote side of your SSH connection, the address is localhost:12345 and it doesn't fit. If the tunnel didn't work at all, you would get ERR_CONNECTION_REFUSED, not ERR_EMPTY_RESPONSE. TOOGAM's answer is right: in general you can build tunnels this way.
    – Kamil Maciorowski
    Jan 19 '18 at 7:44










  • @KamilMaciorowski I see. That means the empty response is generated by the http server right? Because of invalid domain/hostname? But when I type localhost:8081 is the http server, I can access the page. In this case the requesting hosename is localhost too!
    – mannok
    Jan 19 '18 at 8:01
















1














I am using Putty to achieve SSH Reverse Tunnel Port Forwarding. Most of the tutorials are teaching me to forward remote port to localhost port. However, may I know is it make sense to input other host such as 192.168.1.132:8081 into the Destination field?



I have tried to do that. 192.168.1.132:8081 is a working web server with a contented page, but I got ERR_EMPTY_RESPONSE when I visit localhost:12345 (I set port 12345 as the source port) from the client device.





My Putty Configurations



Outgoing Proxy configuration:



Outgoing Proxy configuration



Tunneling config (the Dynamic one is for the Socks5 connection, please just ignore it; the R12345 one is the tunnel that I am playing with):



Tunneling config



The result that I try to access the tunnel from the Destination (SSH Server):



The result that I try to access the tunnel from the Destination (SSH Server)



Can anyone help me?





UPDATE 1



In the device that I am running SSH command, I am going out with via a proxy server. Is that affecting the reverse tunnel behavior?





UPDATE 2



I have tried to make the reverse tunnel from the http server directly. However, in the SSH server I can visit the website by http://localhost:12345. Attched setting and result at below.



Same, http server needed to go out via my office's http proxy too!



Create a reverse tunnel from http server



And then I can visit the http server from SSH server via localhost:12345










share|improve this question
























  • @KamilMaciorowski Sorry for undetailed question. I have updated the question with some image.
    – mannok
    Jan 19 '18 at 7:08






  • 1




    What happens when you browse 192.168.1.132:8081 from the SSH client? (with no SSH involved in this case at all). Do you see proper page?
    – Kamil Maciorowski
    Jan 19 '18 at 7:21










  • @KamilMaciorowski Sure, normal page, normal performance
    – mannok
    Jan 19 '18 at 7:34






  • 1




    Please read this. The HTTP server at 192.168.1.132:8081 may ignore requests destined to addresses other than 192.168.1.132. When you connect from the remote side of your SSH connection, the address is localhost:12345 and it doesn't fit. If the tunnel didn't work at all, you would get ERR_CONNECTION_REFUSED, not ERR_EMPTY_RESPONSE. TOOGAM's answer is right: in general you can build tunnels this way.
    – Kamil Maciorowski
    Jan 19 '18 at 7:44










  • @KamilMaciorowski I see. That means the empty response is generated by the http server right? Because of invalid domain/hostname? But when I type localhost:8081 is the http server, I can access the page. In this case the requesting hosename is localhost too!
    – mannok
    Jan 19 '18 at 8:01














1












1








1







I am using Putty to achieve SSH Reverse Tunnel Port Forwarding. Most of the tutorials are teaching me to forward remote port to localhost port. However, may I know is it make sense to input other host such as 192.168.1.132:8081 into the Destination field?



I have tried to do that. 192.168.1.132:8081 is a working web server with a contented page, but I got ERR_EMPTY_RESPONSE when I visit localhost:12345 (I set port 12345 as the source port) from the client device.





My Putty Configurations



Outgoing Proxy configuration:



Outgoing Proxy configuration



Tunneling config (the Dynamic one is for the Socks5 connection, please just ignore it; the R12345 one is the tunnel that I am playing with):



Tunneling config



The result that I try to access the tunnel from the Destination (SSH Server):



The result that I try to access the tunnel from the Destination (SSH Server)



Can anyone help me?





UPDATE 1



In the device that I am running SSH command, I am going out with via a proxy server. Is that affecting the reverse tunnel behavior?





UPDATE 2



I have tried to make the reverse tunnel from the http server directly. However, in the SSH server I can visit the website by http://localhost:12345. Attched setting and result at below.



Same, http server needed to go out via my office's http proxy too!



Create a reverse tunnel from http server



And then I can visit the http server from SSH server via localhost:12345










share|improve this question















I am using Putty to achieve SSH Reverse Tunnel Port Forwarding. Most of the tutorials are teaching me to forward remote port to localhost port. However, may I know is it make sense to input other host such as 192.168.1.132:8081 into the Destination field?



I have tried to do that. 192.168.1.132:8081 is a working web server with a contented page, but I got ERR_EMPTY_RESPONSE when I visit localhost:12345 (I set port 12345 as the source port) from the client device.





My Putty Configurations



Outgoing Proxy configuration:



Outgoing Proxy configuration



Tunneling config (the Dynamic one is for the Socks5 connection, please just ignore it; the R12345 one is the tunnel that I am playing with):



Tunneling config



The result that I try to access the tunnel from the Destination (SSH Server):



The result that I try to access the tunnel from the Destination (SSH Server)



Can anyone help me?





UPDATE 1



In the device that I am running SSH command, I am going out with via a proxy server. Is that affecting the reverse tunnel behavior?





UPDATE 2



I have tried to make the reverse tunnel from the http server directly. However, in the SSH server I can visit the website by http://localhost:12345. Attched setting and result at below.



Same, http server needed to go out via my office's http proxy too!



Create a reverse tunnel from http server



And then I can visit the http server from SSH server via localhost:12345







ssh port-forwarding putty ssh-tunnel reverse-tunnel






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 19 '18 at 8:23

























asked Jan 19 '18 at 6:45









mannok

1083




1083












  • @KamilMaciorowski Sorry for undetailed question. I have updated the question with some image.
    – mannok
    Jan 19 '18 at 7:08






  • 1




    What happens when you browse 192.168.1.132:8081 from the SSH client? (with no SSH involved in this case at all). Do you see proper page?
    – Kamil Maciorowski
    Jan 19 '18 at 7:21










  • @KamilMaciorowski Sure, normal page, normal performance
    – mannok
    Jan 19 '18 at 7:34






  • 1




    Please read this. The HTTP server at 192.168.1.132:8081 may ignore requests destined to addresses other than 192.168.1.132. When you connect from the remote side of your SSH connection, the address is localhost:12345 and it doesn't fit. If the tunnel didn't work at all, you would get ERR_CONNECTION_REFUSED, not ERR_EMPTY_RESPONSE. TOOGAM's answer is right: in general you can build tunnels this way.
    – Kamil Maciorowski
    Jan 19 '18 at 7:44










  • @KamilMaciorowski I see. That means the empty response is generated by the http server right? Because of invalid domain/hostname? But when I type localhost:8081 is the http server, I can access the page. In this case the requesting hosename is localhost too!
    – mannok
    Jan 19 '18 at 8:01


















  • @KamilMaciorowski Sorry for undetailed question. I have updated the question with some image.
    – mannok
    Jan 19 '18 at 7:08






  • 1




    What happens when you browse 192.168.1.132:8081 from the SSH client? (with no SSH involved in this case at all). Do you see proper page?
    – Kamil Maciorowski
    Jan 19 '18 at 7:21










  • @KamilMaciorowski Sure, normal page, normal performance
    – mannok
    Jan 19 '18 at 7:34






  • 1




    Please read this. The HTTP server at 192.168.1.132:8081 may ignore requests destined to addresses other than 192.168.1.132. When you connect from the remote side of your SSH connection, the address is localhost:12345 and it doesn't fit. If the tunnel didn't work at all, you would get ERR_CONNECTION_REFUSED, not ERR_EMPTY_RESPONSE. TOOGAM's answer is right: in general you can build tunnels this way.
    – Kamil Maciorowski
    Jan 19 '18 at 7:44










  • @KamilMaciorowski I see. That means the empty response is generated by the http server right? Because of invalid domain/hostname? But when I type localhost:8081 is the http server, I can access the page. In this case the requesting hosename is localhost too!
    – mannok
    Jan 19 '18 at 8:01
















@KamilMaciorowski Sorry for undetailed question. I have updated the question with some image.
– mannok
Jan 19 '18 at 7:08




@KamilMaciorowski Sorry for undetailed question. I have updated the question with some image.
– mannok
Jan 19 '18 at 7:08




1




1




What happens when you browse 192.168.1.132:8081 from the SSH client? (with no SSH involved in this case at all). Do you see proper page?
– Kamil Maciorowski
Jan 19 '18 at 7:21




What happens when you browse 192.168.1.132:8081 from the SSH client? (with no SSH involved in this case at all). Do you see proper page?
– Kamil Maciorowski
Jan 19 '18 at 7:21












@KamilMaciorowski Sure, normal page, normal performance
– mannok
Jan 19 '18 at 7:34




@KamilMaciorowski Sure, normal page, normal performance
– mannok
Jan 19 '18 at 7:34




1




1




Please read this. The HTTP server at 192.168.1.132:8081 may ignore requests destined to addresses other than 192.168.1.132. When you connect from the remote side of your SSH connection, the address is localhost:12345 and it doesn't fit. If the tunnel didn't work at all, you would get ERR_CONNECTION_REFUSED, not ERR_EMPTY_RESPONSE. TOOGAM's answer is right: in general you can build tunnels this way.
– Kamil Maciorowski
Jan 19 '18 at 7:44




Please read this. The HTTP server at 192.168.1.132:8081 may ignore requests destined to addresses other than 192.168.1.132. When you connect from the remote side of your SSH connection, the address is localhost:12345 and it doesn't fit. If the tunnel didn't work at all, you would get ERR_CONNECTION_REFUSED, not ERR_EMPTY_RESPONSE. TOOGAM's answer is right: in general you can build tunnels this way.
– Kamil Maciorowski
Jan 19 '18 at 7:44












@KamilMaciorowski I see. That means the empty response is generated by the http server right? Because of invalid domain/hostname? But when I type localhost:8081 is the http server, I can access the page. In this case the requesting hosename is localhost too!
– mannok
Jan 19 '18 at 8:01




@KamilMaciorowski I see. That means the empty response is generated by the http server right? Because of invalid domain/hostname? But when I type localhost:8081 is the http server, I can access the page. In this case the requesting hosename is localhost too!
– mannok
Jan 19 '18 at 8:01










3 Answers
3






active

oldest

votes


















1














Yes!



BUT you need to understand, that this other_host that you will be specifying is at the context of the LAN network of the ssh client. Because the ssh client and the ssh server could be in two different LAN networks.



For example:



ssh -R 1234:192.168.1.69:4321 johnny@terabithia.com
# ^
# |_ other_host


Then, you better be sure that 192.168.1.69 is pingable from your end (the ssh client). There could be a machine with similar ip address of 192.168.1.69 within terabithia.com's reach in terabithia's network LAN, but that is not the other_host that is being referred to in the above snippet.



Some subtle things to take note of:




  • Despite you setup a listening tcp port 1234 inside terabithia.com, but this not publicly accessible in terabithia.com. Meaning that, if you check for port opening by nc -w 5 -z terabithia.com 12202 && echo "open" || echo "close" then you will see the close message printed as the port is only accessible inside terabithia.com.

  • The command nc -w 5 -z localhost 1234 always succeeds inside terabithia.com even if there is no listening port in the other_host or even if other_host is non-existent at all. In this cases, the error messages are printed in the ssh client console.

  • As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as nc or socat to forward UDP ports.

  • Two major confusion is the use of -R versus -L. The trick for easy understanding this topic is to think that the ssh client and the ssh server belongs to two different network LANs. The context of other_host is taken from the ssh client's LAN if -R is used. Otherwise if -L, then the context is taken at the ssh server's LAN.

  • Only -L can open a publicly accessible port if you add the address binding field.






share|improve this answer































    0














    Yes, you can do that, but if you don't understand how it works, it is easy to make incorrect assumptions.



    If I recall correctly (it's been a several months, so in the interest of getting you an answer quickly, I hope I'm getting this right...)

    a tunnel specified as with the "Local" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH client. A "Remote" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH server.



    Understanding Localhost with Tunnels:

    Now, here's the really tricky part that can easily through you for a loop. Normally, when you're on one computer, you think that "localhost" refers to that computer. But, um, no. It is best to think of the "destination" field as text. So after the listener receives traffic, the listener will forward that traffic through the local SSH software, which will encrypt the data and push the traffic through the tunnel. The side that is sending the traffic will also provide the "destination" information. Then the remote SSH software will receive that traffic, and look at what the destination says, and then try to send the traffic there.



    So, if you type "localhost" on your client, the text "localhost" gets sent through the SSH tunnel, and it is actually the remote end which will resolve "localhost". So, localhost can easily refer to a different machine than the machine you type the name on.






    share|improve this answer

















    • 1




      Your general answer is right but the "localhost" explanation is rather opaque, especially in context of the question, because: (1) OP's SSH settings don't involve localhost at all; the only usage is localhost:12345 in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it was localhost or whatever) is resolved locally anyway. Destination is resolved on the non-listening end of any tunnel. The confusion may appear in case of local forwarding (example) where non-listening end is the remote one.
      – Kamil Maciorowski
      Jan 19 '18 at 8:04



















    0














    Can I use other host instead of localhost for Destination Field in SSH Reverse Tunnel Port Forwarding?



    Yes, you can put any host you want in the destination host field



    Command line tunnel definitions



    For the purposes of this answer I will use the form X:Y:Z, which is how the command line SSH client describes tunnels, where this tunnel:




    • Source Port


      • 1234



    • Destination


      • localhost:4321




    would be described as 1234:localhost:4321



    How tunnels work



    There are 2 types of tunnels that have a destination set:



    Local tunnels



    For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the client at port X, and the server connecting to host Y on port Z, and forwarding any traffic through.



    Remote tunnels



    For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the server at port X, and the client connecting to host Y on port Z, and forwarding any traffic through.



    What can you use tunnels for



    Local tunnels can be used for:




    • Accessing services that are not accessible over the internet

    • Accessing services that can only be used from a specific IP


    Remote tunnels can be used for:




    • Allowing remote systems to access ports on your local machine without exposing them to the internet

    • Exposing other systems on your network over the internet






    share|improve this answer





















      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "3"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1287014%2fcan-i-use-other-host-instead-of-localhost-for-destination-field-in-ssh-reverse-t%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      1














      Yes!



      BUT you need to understand, that this other_host that you will be specifying is at the context of the LAN network of the ssh client. Because the ssh client and the ssh server could be in two different LAN networks.



      For example:



      ssh -R 1234:192.168.1.69:4321 johnny@terabithia.com
      # ^
      # |_ other_host


      Then, you better be sure that 192.168.1.69 is pingable from your end (the ssh client). There could be a machine with similar ip address of 192.168.1.69 within terabithia.com's reach in terabithia's network LAN, but that is not the other_host that is being referred to in the above snippet.



      Some subtle things to take note of:




      • Despite you setup a listening tcp port 1234 inside terabithia.com, but this not publicly accessible in terabithia.com. Meaning that, if you check for port opening by nc -w 5 -z terabithia.com 12202 && echo "open" || echo "close" then you will see the close message printed as the port is only accessible inside terabithia.com.

      • The command nc -w 5 -z localhost 1234 always succeeds inside terabithia.com even if there is no listening port in the other_host or even if other_host is non-existent at all. In this cases, the error messages are printed in the ssh client console.

      • As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as nc or socat to forward UDP ports.

      • Two major confusion is the use of -R versus -L. The trick for easy understanding this topic is to think that the ssh client and the ssh server belongs to two different network LANs. The context of other_host is taken from the ssh client's LAN if -R is used. Otherwise if -L, then the context is taken at the ssh server's LAN.

      • Only -L can open a publicly accessible port if you add the address binding field.






      share|improve this answer




























        1














        Yes!



        BUT you need to understand, that this other_host that you will be specifying is at the context of the LAN network of the ssh client. Because the ssh client and the ssh server could be in two different LAN networks.



        For example:



        ssh -R 1234:192.168.1.69:4321 johnny@terabithia.com
        # ^
        # |_ other_host


        Then, you better be sure that 192.168.1.69 is pingable from your end (the ssh client). There could be a machine with similar ip address of 192.168.1.69 within terabithia.com's reach in terabithia's network LAN, but that is not the other_host that is being referred to in the above snippet.



        Some subtle things to take note of:




        • Despite you setup a listening tcp port 1234 inside terabithia.com, but this not publicly accessible in terabithia.com. Meaning that, if you check for port opening by nc -w 5 -z terabithia.com 12202 && echo "open" || echo "close" then you will see the close message printed as the port is only accessible inside terabithia.com.

        • The command nc -w 5 -z localhost 1234 always succeeds inside terabithia.com even if there is no listening port in the other_host or even if other_host is non-existent at all. In this cases, the error messages are printed in the ssh client console.

        • As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as nc or socat to forward UDP ports.

        • Two major confusion is the use of -R versus -L. The trick for easy understanding this topic is to think that the ssh client and the ssh server belongs to two different network LANs. The context of other_host is taken from the ssh client's LAN if -R is used. Otherwise if -L, then the context is taken at the ssh server's LAN.

        • Only -L can open a publicly accessible port if you add the address binding field.






        share|improve this answer


























          1












          1








          1






          Yes!



          BUT you need to understand, that this other_host that you will be specifying is at the context of the LAN network of the ssh client. Because the ssh client and the ssh server could be in two different LAN networks.



          For example:



          ssh -R 1234:192.168.1.69:4321 johnny@terabithia.com
          # ^
          # |_ other_host


          Then, you better be sure that 192.168.1.69 is pingable from your end (the ssh client). There could be a machine with similar ip address of 192.168.1.69 within terabithia.com's reach in terabithia's network LAN, but that is not the other_host that is being referred to in the above snippet.



          Some subtle things to take note of:




          • Despite you setup a listening tcp port 1234 inside terabithia.com, but this not publicly accessible in terabithia.com. Meaning that, if you check for port opening by nc -w 5 -z terabithia.com 12202 && echo "open" || echo "close" then you will see the close message printed as the port is only accessible inside terabithia.com.

          • The command nc -w 5 -z localhost 1234 always succeeds inside terabithia.com even if there is no listening port in the other_host or even if other_host is non-existent at all. In this cases, the error messages are printed in the ssh client console.

          • As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as nc or socat to forward UDP ports.

          • Two major confusion is the use of -R versus -L. The trick for easy understanding this topic is to think that the ssh client and the ssh server belongs to two different network LANs. The context of other_host is taken from the ssh client's LAN if -R is used. Otherwise if -L, then the context is taken at the ssh server's LAN.

          • Only -L can open a publicly accessible port if you add the address binding field.






          share|improve this answer














          Yes!



          BUT you need to understand, that this other_host that you will be specifying is at the context of the LAN network of the ssh client. Because the ssh client and the ssh server could be in two different LAN networks.



          For example:



          ssh -R 1234:192.168.1.69:4321 johnny@terabithia.com
          # ^
          # |_ other_host


          Then, you better be sure that 192.168.1.69 is pingable from your end (the ssh client). There could be a machine with similar ip address of 192.168.1.69 within terabithia.com's reach in terabithia's network LAN, but that is not the other_host that is being referred to in the above snippet.



          Some subtle things to take note of:




          • Despite you setup a listening tcp port 1234 inside terabithia.com, but this not publicly accessible in terabithia.com. Meaning that, if you check for port opening by nc -w 5 -z terabithia.com 12202 && echo "open" || echo "close" then you will see the close message printed as the port is only accessible inside terabithia.com.

          • The command nc -w 5 -z localhost 1234 always succeeds inside terabithia.com even if there is no listening port in the other_host or even if other_host is non-existent at all. In this cases, the error messages are printed in the ssh client console.

          • As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as nc or socat to forward UDP ports.

          • Two major confusion is the use of -R versus -L. The trick for easy understanding this topic is to think that the ssh client and the ssh server belongs to two different network LANs. The context of other_host is taken from the ssh client's LAN if -R is used. Otherwise if -L, then the context is taken at the ssh server's LAN.

          • Only -L can open a publicly accessible port if you add the address binding field.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 6 '18 at 19:23

























          answered Dec 6 '18 at 17:52









          daixtr

          1114




          1114

























              0














              Yes, you can do that, but if you don't understand how it works, it is easy to make incorrect assumptions.



              If I recall correctly (it's been a several months, so in the interest of getting you an answer quickly, I hope I'm getting this right...)

              a tunnel specified as with the "Local" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH client. A "Remote" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH server.



              Understanding Localhost with Tunnels:

              Now, here's the really tricky part that can easily through you for a loop. Normally, when you're on one computer, you think that "localhost" refers to that computer. But, um, no. It is best to think of the "destination" field as text. So after the listener receives traffic, the listener will forward that traffic through the local SSH software, which will encrypt the data and push the traffic through the tunnel. The side that is sending the traffic will also provide the "destination" information. Then the remote SSH software will receive that traffic, and look at what the destination says, and then try to send the traffic there.



              So, if you type "localhost" on your client, the text "localhost" gets sent through the SSH tunnel, and it is actually the remote end which will resolve "localhost". So, localhost can easily refer to a different machine than the machine you type the name on.






              share|improve this answer

















              • 1




                Your general answer is right but the "localhost" explanation is rather opaque, especially in context of the question, because: (1) OP's SSH settings don't involve localhost at all; the only usage is localhost:12345 in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it was localhost or whatever) is resolved locally anyway. Destination is resolved on the non-listening end of any tunnel. The confusion may appear in case of local forwarding (example) where non-listening end is the remote one.
                – Kamil Maciorowski
                Jan 19 '18 at 8:04
















              0














              Yes, you can do that, but if you don't understand how it works, it is easy to make incorrect assumptions.



              If I recall correctly (it's been a several months, so in the interest of getting you an answer quickly, I hope I'm getting this right...)

              a tunnel specified as with the "Local" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH client. A "Remote" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH server.



              Understanding Localhost with Tunnels:

              Now, here's the really tricky part that can easily through you for a loop. Normally, when you're on one computer, you think that "localhost" refers to that computer. But, um, no. It is best to think of the "destination" field as text. So after the listener receives traffic, the listener will forward that traffic through the local SSH software, which will encrypt the data and push the traffic through the tunnel. The side that is sending the traffic will also provide the "destination" information. Then the remote SSH software will receive that traffic, and look at what the destination says, and then try to send the traffic there.



              So, if you type "localhost" on your client, the text "localhost" gets sent through the SSH tunnel, and it is actually the remote end which will resolve "localhost". So, localhost can easily refer to a different machine than the machine you type the name on.






              share|improve this answer

















              • 1




                Your general answer is right but the "localhost" explanation is rather opaque, especially in context of the question, because: (1) OP's SSH settings don't involve localhost at all; the only usage is localhost:12345 in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it was localhost or whatever) is resolved locally anyway. Destination is resolved on the non-listening end of any tunnel. The confusion may appear in case of local forwarding (example) where non-listening end is the remote one.
                – Kamil Maciorowski
                Jan 19 '18 at 8:04














              0












              0








              0






              Yes, you can do that, but if you don't understand how it works, it is easy to make incorrect assumptions.



              If I recall correctly (it's been a several months, so in the interest of getting you an answer quickly, I hope I'm getting this right...)

              a tunnel specified as with the "Local" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH client. A "Remote" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH server.



              Understanding Localhost with Tunnels:

              Now, here's the really tricky part that can easily through you for a loop. Normally, when you're on one computer, you think that "localhost" refers to that computer. But, um, no. It is best to think of the "destination" field as text. So after the listener receives traffic, the listener will forward that traffic through the local SSH software, which will encrypt the data and push the traffic through the tunnel. The side that is sending the traffic will also provide the "destination" information. Then the remote SSH software will receive that traffic, and look at what the destination says, and then try to send the traffic there.



              So, if you type "localhost" on your client, the text "localhost" gets sent through the SSH tunnel, and it is actually the remote end which will resolve "localhost". So, localhost can easily refer to a different machine than the machine you type the name on.






              share|improve this answer












              Yes, you can do that, but if you don't understand how it works, it is easy to make incorrect assumptions.



              If I recall correctly (it's been a several months, so in the interest of getting you an answer quickly, I hope I'm getting this right...)

              a tunnel specified as with the "Local" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH client. A "Remote" port will cause a piece of software, which I will call a "listener", to listen on the machine running the SSH server.



              Understanding Localhost with Tunnels:

              Now, here's the really tricky part that can easily through you for a loop. Normally, when you're on one computer, you think that "localhost" refers to that computer. But, um, no. It is best to think of the "destination" field as text. So after the listener receives traffic, the listener will forward that traffic through the local SSH software, which will encrypt the data and push the traffic through the tunnel. The side that is sending the traffic will also provide the "destination" information. Then the remote SSH software will receive that traffic, and look at what the destination says, and then try to send the traffic there.



              So, if you type "localhost" on your client, the text "localhost" gets sent through the SSH tunnel, and it is actually the remote end which will resolve "localhost". So, localhost can easily refer to a different machine than the machine you type the name on.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Jan 19 '18 at 6:56









              TOOGAM

              11.3k32643




              11.3k32643








              • 1




                Your general answer is right but the "localhost" explanation is rather opaque, especially in context of the question, because: (1) OP's SSH settings don't involve localhost at all; the only usage is localhost:12345 in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it was localhost or whatever) is resolved locally anyway. Destination is resolved on the non-listening end of any tunnel. The confusion may appear in case of local forwarding (example) where non-listening end is the remote one.
                – Kamil Maciorowski
                Jan 19 '18 at 8:04














              • 1




                Your general answer is right but the "localhost" explanation is rather opaque, especially in context of the question, because: (1) OP's SSH settings don't involve localhost at all; the only usage is localhost:12345 in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it was localhost or whatever) is resolved locally anyway. Destination is resolved on the non-listening end of any tunnel. The confusion may appear in case of local forwarding (example) where non-listening end is the remote one.
                – Kamil Maciorowski
                Jan 19 '18 at 8:04








              1




              1




              Your general answer is right but the "localhost" explanation is rather opaque, especially in context of the question, because: (1) OP's SSH settings don't involve localhost at all; the only usage is localhost:12345 in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it was localhost or whatever) is resolved locally anyway. Destination is resolved on the non-listening end of any tunnel. The confusion may appear in case of local forwarding (example) where non-listening end is the remote one.
              – Kamil Maciorowski
              Jan 19 '18 at 8:04




              Your general answer is right but the "localhost" explanation is rather opaque, especially in context of the question, because: (1) OP's SSH settings don't involve localhost at all; the only usage is localhost:12345 in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it was localhost or whatever) is resolved locally anyway. Destination is resolved on the non-listening end of any tunnel. The confusion may appear in case of local forwarding (example) where non-listening end is the remote one.
              – Kamil Maciorowski
              Jan 19 '18 at 8:04











              0














              Can I use other host instead of localhost for Destination Field in SSH Reverse Tunnel Port Forwarding?



              Yes, you can put any host you want in the destination host field



              Command line tunnel definitions



              For the purposes of this answer I will use the form X:Y:Z, which is how the command line SSH client describes tunnels, where this tunnel:




              • Source Port


                • 1234



              • Destination


                • localhost:4321




              would be described as 1234:localhost:4321



              How tunnels work



              There are 2 types of tunnels that have a destination set:



              Local tunnels



              For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the client at port X, and the server connecting to host Y on port Z, and forwarding any traffic through.



              Remote tunnels



              For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the server at port X, and the client connecting to host Y on port Z, and forwarding any traffic through.



              What can you use tunnels for



              Local tunnels can be used for:




              • Accessing services that are not accessible over the internet

              • Accessing services that can only be used from a specific IP


              Remote tunnels can be used for:




              • Allowing remote systems to access ports on your local machine without exposing them to the internet

              • Exposing other systems on your network over the internet






              share|improve this answer


























                0














                Can I use other host instead of localhost for Destination Field in SSH Reverse Tunnel Port Forwarding?



                Yes, you can put any host you want in the destination host field



                Command line tunnel definitions



                For the purposes of this answer I will use the form X:Y:Z, which is how the command line SSH client describes tunnels, where this tunnel:




                • Source Port


                  • 1234



                • Destination


                  • localhost:4321




                would be described as 1234:localhost:4321



                How tunnels work



                There are 2 types of tunnels that have a destination set:



                Local tunnels



                For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the client at port X, and the server connecting to host Y on port Z, and forwarding any traffic through.



                Remote tunnels



                For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the server at port X, and the client connecting to host Y on port Z, and forwarding any traffic through.



                What can you use tunnels for



                Local tunnels can be used for:




                • Accessing services that are not accessible over the internet

                • Accessing services that can only be used from a specific IP


                Remote tunnels can be used for:




                • Allowing remote systems to access ports on your local machine without exposing them to the internet

                • Exposing other systems on your network over the internet






                share|improve this answer
























                  0












                  0








                  0






                  Can I use other host instead of localhost for Destination Field in SSH Reverse Tunnel Port Forwarding?



                  Yes, you can put any host you want in the destination host field



                  Command line tunnel definitions



                  For the purposes of this answer I will use the form X:Y:Z, which is how the command line SSH client describes tunnels, where this tunnel:




                  • Source Port


                    • 1234



                  • Destination


                    • localhost:4321




                  would be described as 1234:localhost:4321



                  How tunnels work



                  There are 2 types of tunnels that have a destination set:



                  Local tunnels



                  For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the client at port X, and the server connecting to host Y on port Z, and forwarding any traffic through.



                  Remote tunnels



                  For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the server at port X, and the client connecting to host Y on port Z, and forwarding any traffic through.



                  What can you use tunnels for



                  Local tunnels can be used for:




                  • Accessing services that are not accessible over the internet

                  • Accessing services that can only be used from a specific IP


                  Remote tunnels can be used for:




                  • Allowing remote systems to access ports on your local machine without exposing them to the internet

                  • Exposing other systems on your network over the internet






                  share|improve this answer












                  Can I use other host instead of localhost for Destination Field in SSH Reverse Tunnel Port Forwarding?



                  Yes, you can put any host you want in the destination host field



                  Command line tunnel definitions



                  For the purposes of this answer I will use the form X:Y:Z, which is how the command line SSH client describes tunnels, where this tunnel:




                  • Source Port


                    • 1234



                  • Destination


                    • localhost:4321




                  would be described as 1234:localhost:4321



                  How tunnels work



                  There are 2 types of tunnels that have a destination set:



                  Local tunnels



                  For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the client at port X, and the server connecting to host Y on port Z, and forwarding any traffic through.



                  Remote tunnels



                  For a tunnel defined as X:Y:Z you can treat the traffic as being sent into the server at port X, and the client connecting to host Y on port Z, and forwarding any traffic through.



                  What can you use tunnels for



                  Local tunnels can be used for:




                  • Accessing services that are not accessible over the internet

                  • Accessing services that can only be used from a specific IP


                  Remote tunnels can be used for:




                  • Allowing remote systems to access ports on your local machine without exposing them to the internet

                  • Exposing other systems on your network over the internet







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 19 '18 at 9:34









                  jrtapsell

                  378110




                  378110






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Super User!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1287014%2fcan-i-use-other-host-instead-of-localhost-for-destination-field-in-ssh-reverse-t%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Сан-Квентин

                      Алькесар

                      Josef Freinademetz