Can I use other host instead of localhost for Destination Field in SSH Reverse Tunnel Port Forwarding?
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:
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):
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
|
show 6 more comments
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:
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):
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
@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 browse192.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 at192.168.1.132:8081
may ignore requests destined to addresses other than192.168.1.132
. When you connect from the remote side of your SSH connection, the address islocalhost:12345
and it doesn't fit. If the tunnel didn't work at all, you would getERR_CONNECTION_REFUSED
, notERR_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
|
show 6 more comments
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:
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):
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
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:
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):
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
ssh port-forwarding putty ssh-tunnel reverse-tunnel
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 browse192.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 at192.168.1.132:8081
may ignore requests destined to addresses other than192.168.1.132
. When you connect from the remote side of your SSH connection, the address islocalhost:12345
and it doesn't fit. If the tunnel didn't work at all, you would getERR_CONNECTION_REFUSED
, notERR_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
|
show 6 more comments
@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 browse192.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 at192.168.1.132:8081
may ignore requests destined to addresses other than192.168.1.132
. When you connect from the remote side of your SSH connection, the address islocalhost:12345
and it doesn't fit. If the tunnel didn't work at all, you would getERR_CONNECTION_REFUSED
, notERR_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
|
show 6 more comments
3 Answers
3
active
oldest
votes
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 theclose
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 theother_host
or even ifother_host
is non-existent at all. In this cases, the error messages are printed in thessh client
console. - As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as
nc
orsocat
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 thessh client
and thessh server
belongs to two different network LANs. The context ofother_host
is taken from thessh client's
LAN if-R
is used. Otherwise if-L
, then the context is taken at thessh server's
LAN. - Only
-L
can open a publicly accessible port if you add theaddress binding
field.
add a comment |
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.
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 involvelocalhost
at all; the only usage islocalhost:12345
in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it waslocalhost
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
add a comment |
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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 theclose
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 theother_host
or even ifother_host
is non-existent at all. In this cases, the error messages are printed in thessh client
console. - As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as
nc
orsocat
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 thessh client
and thessh server
belongs to two different network LANs. The context ofother_host
is taken from thessh client's
LAN if-R
is used. Otherwise if-L
, then the context is taken at thessh server's
LAN. - Only
-L
can open a publicly accessible port if you add theaddress binding
field.
add a comment |
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 theclose
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 theother_host
or even ifother_host
is non-existent at all. In this cases, the error messages are printed in thessh client
console. - As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as
nc
orsocat
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 thessh client
and thessh server
belongs to two different network LANs. The context ofother_host
is taken from thessh client's
LAN if-R
is used. Otherwise if-L
, then the context is taken at thessh server's
LAN. - Only
-L
can open a publicly accessible port if you add theaddress binding
field.
add a comment |
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 theclose
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 theother_host
or even ifother_host
is non-existent at all. In this cases, the error messages are printed in thessh client
console. - As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as
nc
orsocat
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 thessh client
and thessh server
belongs to two different network LANs. The context ofother_host
is taken from thessh client's
LAN if-R
is used. Otherwise if-L
, then the context is taken at thessh server's
LAN. - Only
-L
can open a publicly accessible port if you add theaddress binding
field.
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 theclose
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 theother_host
or even ifother_host
is non-existent at all. In this cases, the error messages are printed in thessh client
console. - As ssh is tcp-based connection-oriented communication protocol therefore, you will need other tools in combination such as
nc
orsocat
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 thessh client
and thessh server
belongs to two different network LANs. The context ofother_host
is taken from thessh client's
LAN if-R
is used. Otherwise if-L
, then the context is taken at thessh server's
LAN. - Only
-L
can open a publicly accessible port if you add theaddress binding
field.
edited Dec 6 '18 at 19:23
answered Dec 6 '18 at 17:52
daixtr
1114
1114
add a comment |
add a comment |
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.
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 involvelocalhost
at all; the only usage islocalhost:12345
in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it waslocalhost
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
add a comment |
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.
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 involvelocalhost
at all; the only usage islocalhost:12345
in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it waslocalhost
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
add a comment |
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.
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.
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 involvelocalhost
at all; the only usage islocalhost:12345
in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it waslocalhost
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
add a comment |
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 involvelocalhost
at all; the only usage islocalhost:12345
in the remote side browser, which is right. (2) We're talking about remote forwarding, so the destination (if it waslocalhost
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
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Jan 19 '18 at 9:34
jrtapsell
378110
378110
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
@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 than192.168.1.132
. When you connect from the remote side of your SSH connection, the address islocalhost:12345
and it doesn't fit. If the tunnel didn't work at all, you would getERR_CONNECTION_REFUSED
, notERR_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