ssh reverse tunnel with remote ip
From a server 192.168.0.1, I'd like to reach a server 192.168.0.2 on port 80.
192.168.0.2 can reach 192.168.0.1, but 192.168.0.1 can't reach 192.168.0.2 (firewall).
I have set up a reverse proxy, by typing the following command on 192.168.0.2:
ssh -f -N -T -R0.0.0.0:80:localhost:80 192.168.0.1
now 192.168.0.1 can reach 192.168.0.2, with the following command:
wget localhost:80
However I'd like to be able to reach 192.168.0.2 by taping
wget 192.168.0.2:80
Is this possible, without messing with the DNS?
linux ssh networking ssh-tunneling
bumped to the homepage by Community♦ 5 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
From a server 192.168.0.1, I'd like to reach a server 192.168.0.2 on port 80.
192.168.0.2 can reach 192.168.0.1, but 192.168.0.1 can't reach 192.168.0.2 (firewall).
I have set up a reverse proxy, by typing the following command on 192.168.0.2:
ssh -f -N -T -R0.0.0.0:80:localhost:80 192.168.0.1
now 192.168.0.1 can reach 192.168.0.2, with the following command:
wget localhost:80
However I'd like to be able to reach 192.168.0.2 by taping
wget 192.168.0.2:80
Is this possible, without messing with the DNS?
linux ssh networking ssh-tunneling
bumped to the homepage by Community♦ 5 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
1
superuser.com/questions/661772/iptables-redirect-to-localhost
– 7171u
Mar 1 '16 at 14:04
@7171u ok thanks, I have added a rule so that iptables -t nat -L shows: DNAT tcp -- anywhere 192.168.0.2 tcp dpt:http to:127.0.0.1:80 however, the second wget is still not working, what could be wrong?
– rogerJ
Mar 1 '16 at 14:32
I have used this on RHEL7 and it works fine.
– 7171u
Mar 1 '16 at 15:01
add a comment |
From a server 192.168.0.1, I'd like to reach a server 192.168.0.2 on port 80.
192.168.0.2 can reach 192.168.0.1, but 192.168.0.1 can't reach 192.168.0.2 (firewall).
I have set up a reverse proxy, by typing the following command on 192.168.0.2:
ssh -f -N -T -R0.0.0.0:80:localhost:80 192.168.0.1
now 192.168.0.1 can reach 192.168.0.2, with the following command:
wget localhost:80
However I'd like to be able to reach 192.168.0.2 by taping
wget 192.168.0.2:80
Is this possible, without messing with the DNS?
linux ssh networking ssh-tunneling
From a server 192.168.0.1, I'd like to reach a server 192.168.0.2 on port 80.
192.168.0.2 can reach 192.168.0.1, but 192.168.0.1 can't reach 192.168.0.2 (firewall).
I have set up a reverse proxy, by typing the following command on 192.168.0.2:
ssh -f -N -T -R0.0.0.0:80:localhost:80 192.168.0.1
now 192.168.0.1 can reach 192.168.0.2, with the following command:
wget localhost:80
However I'd like to be able to reach 192.168.0.2 by taping
wget 192.168.0.2:80
Is this possible, without messing with the DNS?
linux ssh networking ssh-tunneling
linux ssh networking ssh-tunneling
asked Mar 1 '16 at 13:42
rogerJrogerJ
163
163
bumped to the homepage by Community♦ 5 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 5 hours ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
1
superuser.com/questions/661772/iptables-redirect-to-localhost
– 7171u
Mar 1 '16 at 14:04
@7171u ok thanks, I have added a rule so that iptables -t nat -L shows: DNAT tcp -- anywhere 192.168.0.2 tcp dpt:http to:127.0.0.1:80 however, the second wget is still not working, what could be wrong?
– rogerJ
Mar 1 '16 at 14:32
I have used this on RHEL7 and it works fine.
– 7171u
Mar 1 '16 at 15:01
add a comment |
1
superuser.com/questions/661772/iptables-redirect-to-localhost
– 7171u
Mar 1 '16 at 14:04
@7171u ok thanks, I have added a rule so that iptables -t nat -L shows: DNAT tcp -- anywhere 192.168.0.2 tcp dpt:http to:127.0.0.1:80 however, the second wget is still not working, what could be wrong?
– rogerJ
Mar 1 '16 at 14:32
I have used this on RHEL7 and it works fine.
– 7171u
Mar 1 '16 at 15:01
1
1
superuser.com/questions/661772/iptables-redirect-to-localhost
– 7171u
Mar 1 '16 at 14:04
superuser.com/questions/661772/iptables-redirect-to-localhost
– 7171u
Mar 1 '16 at 14:04
@7171u ok thanks, I have added a rule so that iptables -t nat -L shows: DNAT tcp -- anywhere 192.168.0.2 tcp dpt:http to:127.0.0.1:80 however, the second wget is still not working, what could be wrong?
– rogerJ
Mar 1 '16 at 14:32
@7171u ok thanks, I have added a rule so that iptables -t nat -L shows: DNAT tcp -- anywhere 192.168.0.2 tcp dpt:http to:127.0.0.1:80 however, the second wget is still not working, what could be wrong?
– rogerJ
Mar 1 '16 at 14:32
I have used this on RHEL7 and it works fine.
– 7171u
Mar 1 '16 at 15:01
I have used this on RHEL7 and it works fine.
– 7171u
Mar 1 '16 at 15:01
add a comment |
2 Answers
2
active
oldest
votes
You need to define the GatewayPorts
in sshd_config
otherwise the *
or 0.0.0.0
will bind only to the loopback interface.
Also note that
Privileged ports can be forwarded only when logging in as root on the remote machine.
From manual page for ssh
:
By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a
bind_address
. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remotebind_address
will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).
I have added the following line in /etc/ssh/sshd.config -> GatewayPorts clientspecified. However it still doesn't work.
– rogerJ
Mar 1 '16 at 16:12
Also I would try with*
or address of outer interface (192.168.0.1
) instead of0.0.0.0
and I would watch for errors on both connections.
– Jakuje
Mar 1 '16 at 16:27
I tried both * and 192.168.0.1, to no success. I don't really know what errors to look for, the only thing I can tell you is that the tunnel itself works (wget localhost:80), as explained in the question, so the error is probably not coming from here. What doesn't work is just the wget 192.168.0.2:80, which is maybe an error with the iptables rule
– rogerJ
Mar 1 '16 at 16:42
Why do you trywget 192.168.0.2:80
? You should trywget 192.168.0.1:80
. This is where your port is forwarded, isn't it?
– Jakuje
Mar 1 '16 at 16:54
Well that's the whole point of my question. Say the server I would like to access is google.com, but I can't reach it directly, though google.com can reach me, I'd like to set up my network so that I can reach google.com transparently without having to change anything. So in the end of this configuration, I expect to be able to type wget google.com, not wget localhost or wget 192.168.0.1, which is my own ip.
– rogerJ
Mar 1 '16 at 17:06
|
show 1 more comment
I was struggling with this issue on Ubuntu 14.04 (I tried both GatewayPorts clientspecified
and GatewayPorts yes
in /etc/ssh/sshd_config
).
Instead, adding this to my sshd_config
worked:
Match User !root
GatewayPorts yes
That is, I had to specify a user to match the rule to.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f266772%2fssh-reverse-tunnel-with-remote-ip%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You need to define the GatewayPorts
in sshd_config
otherwise the *
or 0.0.0.0
will bind only to the loopback interface.
Also note that
Privileged ports can be forwarded only when logging in as root on the remote machine.
From manual page for ssh
:
By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a
bind_address
. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remotebind_address
will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).
I have added the following line in /etc/ssh/sshd.config -> GatewayPorts clientspecified. However it still doesn't work.
– rogerJ
Mar 1 '16 at 16:12
Also I would try with*
or address of outer interface (192.168.0.1
) instead of0.0.0.0
and I would watch for errors on both connections.
– Jakuje
Mar 1 '16 at 16:27
I tried both * and 192.168.0.1, to no success. I don't really know what errors to look for, the only thing I can tell you is that the tunnel itself works (wget localhost:80), as explained in the question, so the error is probably not coming from here. What doesn't work is just the wget 192.168.0.2:80, which is maybe an error with the iptables rule
– rogerJ
Mar 1 '16 at 16:42
Why do you trywget 192.168.0.2:80
? You should trywget 192.168.0.1:80
. This is where your port is forwarded, isn't it?
– Jakuje
Mar 1 '16 at 16:54
Well that's the whole point of my question. Say the server I would like to access is google.com, but I can't reach it directly, though google.com can reach me, I'd like to set up my network so that I can reach google.com transparently without having to change anything. So in the end of this configuration, I expect to be able to type wget google.com, not wget localhost or wget 192.168.0.1, which is my own ip.
– rogerJ
Mar 1 '16 at 17:06
|
show 1 more comment
You need to define the GatewayPorts
in sshd_config
otherwise the *
or 0.0.0.0
will bind only to the loopback interface.
Also note that
Privileged ports can be forwarded only when logging in as root on the remote machine.
From manual page for ssh
:
By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a
bind_address
. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remotebind_address
will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).
I have added the following line in /etc/ssh/sshd.config -> GatewayPorts clientspecified. However it still doesn't work.
– rogerJ
Mar 1 '16 at 16:12
Also I would try with*
or address of outer interface (192.168.0.1
) instead of0.0.0.0
and I would watch for errors on both connections.
– Jakuje
Mar 1 '16 at 16:27
I tried both * and 192.168.0.1, to no success. I don't really know what errors to look for, the only thing I can tell you is that the tunnel itself works (wget localhost:80), as explained in the question, so the error is probably not coming from here. What doesn't work is just the wget 192.168.0.2:80, which is maybe an error with the iptables rule
– rogerJ
Mar 1 '16 at 16:42
Why do you trywget 192.168.0.2:80
? You should trywget 192.168.0.1:80
. This is where your port is forwarded, isn't it?
– Jakuje
Mar 1 '16 at 16:54
Well that's the whole point of my question. Say the server I would like to access is google.com, but I can't reach it directly, though google.com can reach me, I'd like to set up my network so that I can reach google.com transparently without having to change anything. So in the end of this configuration, I expect to be able to type wget google.com, not wget localhost or wget 192.168.0.1, which is my own ip.
– rogerJ
Mar 1 '16 at 17:06
|
show 1 more comment
You need to define the GatewayPorts
in sshd_config
otherwise the *
or 0.0.0.0
will bind only to the loopback interface.
Also note that
Privileged ports can be forwarded only when logging in as root on the remote machine.
From manual page for ssh
:
By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a
bind_address
. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remotebind_address
will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).
You need to define the GatewayPorts
in sshd_config
otherwise the *
or 0.0.0.0
will bind only to the loopback interface.
Also note that
Privileged ports can be forwarded only when logging in as root on the remote machine.
From manual page for ssh
:
By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a
bind_address
. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remotebind_address
will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).
answered Mar 1 '16 at 15:07
JakujeJakuje
16.5k53155
16.5k53155
I have added the following line in /etc/ssh/sshd.config -> GatewayPorts clientspecified. However it still doesn't work.
– rogerJ
Mar 1 '16 at 16:12
Also I would try with*
or address of outer interface (192.168.0.1
) instead of0.0.0.0
and I would watch for errors on both connections.
– Jakuje
Mar 1 '16 at 16:27
I tried both * and 192.168.0.1, to no success. I don't really know what errors to look for, the only thing I can tell you is that the tunnel itself works (wget localhost:80), as explained in the question, so the error is probably not coming from here. What doesn't work is just the wget 192.168.0.2:80, which is maybe an error with the iptables rule
– rogerJ
Mar 1 '16 at 16:42
Why do you trywget 192.168.0.2:80
? You should trywget 192.168.0.1:80
. This is where your port is forwarded, isn't it?
– Jakuje
Mar 1 '16 at 16:54
Well that's the whole point of my question. Say the server I would like to access is google.com, but I can't reach it directly, though google.com can reach me, I'd like to set up my network so that I can reach google.com transparently without having to change anything. So in the end of this configuration, I expect to be able to type wget google.com, not wget localhost or wget 192.168.0.1, which is my own ip.
– rogerJ
Mar 1 '16 at 17:06
|
show 1 more comment
I have added the following line in /etc/ssh/sshd.config -> GatewayPorts clientspecified. However it still doesn't work.
– rogerJ
Mar 1 '16 at 16:12
Also I would try with*
or address of outer interface (192.168.0.1
) instead of0.0.0.0
and I would watch for errors on both connections.
– Jakuje
Mar 1 '16 at 16:27
I tried both * and 192.168.0.1, to no success. I don't really know what errors to look for, the only thing I can tell you is that the tunnel itself works (wget localhost:80), as explained in the question, so the error is probably not coming from here. What doesn't work is just the wget 192.168.0.2:80, which is maybe an error with the iptables rule
– rogerJ
Mar 1 '16 at 16:42
Why do you trywget 192.168.0.2:80
? You should trywget 192.168.0.1:80
. This is where your port is forwarded, isn't it?
– Jakuje
Mar 1 '16 at 16:54
Well that's the whole point of my question. Say the server I would like to access is google.com, but I can't reach it directly, though google.com can reach me, I'd like to set up my network so that I can reach google.com transparently without having to change anything. So in the end of this configuration, I expect to be able to type wget google.com, not wget localhost or wget 192.168.0.1, which is my own ip.
– rogerJ
Mar 1 '16 at 17:06
I have added the following line in /etc/ssh/sshd.config -> GatewayPorts clientspecified. However it still doesn't work.
– rogerJ
Mar 1 '16 at 16:12
I have added the following line in /etc/ssh/sshd.config -> GatewayPorts clientspecified. However it still doesn't work.
– rogerJ
Mar 1 '16 at 16:12
Also I would try with
*
or address of outer interface (192.168.0.1
) instead of 0.0.0.0
and I would watch for errors on both connections.– Jakuje
Mar 1 '16 at 16:27
Also I would try with
*
or address of outer interface (192.168.0.1
) instead of 0.0.0.0
and I would watch for errors on both connections.– Jakuje
Mar 1 '16 at 16:27
I tried both * and 192.168.0.1, to no success. I don't really know what errors to look for, the only thing I can tell you is that the tunnel itself works (wget localhost:80), as explained in the question, so the error is probably not coming from here. What doesn't work is just the wget 192.168.0.2:80, which is maybe an error with the iptables rule
– rogerJ
Mar 1 '16 at 16:42
I tried both * and 192.168.0.1, to no success. I don't really know what errors to look for, the only thing I can tell you is that the tunnel itself works (wget localhost:80), as explained in the question, so the error is probably not coming from here. What doesn't work is just the wget 192.168.0.2:80, which is maybe an error with the iptables rule
– rogerJ
Mar 1 '16 at 16:42
Why do you try
wget 192.168.0.2:80
? You should try wget 192.168.0.1:80
. This is where your port is forwarded, isn't it?– Jakuje
Mar 1 '16 at 16:54
Why do you try
wget 192.168.0.2:80
? You should try wget 192.168.0.1:80
. This is where your port is forwarded, isn't it?– Jakuje
Mar 1 '16 at 16:54
Well that's the whole point of my question. Say the server I would like to access is google.com, but I can't reach it directly, though google.com can reach me, I'd like to set up my network so that I can reach google.com transparently without having to change anything. So in the end of this configuration, I expect to be able to type wget google.com, not wget localhost or wget 192.168.0.1, which is my own ip.
– rogerJ
Mar 1 '16 at 17:06
Well that's the whole point of my question. Say the server I would like to access is google.com, but I can't reach it directly, though google.com can reach me, I'd like to set up my network so that I can reach google.com transparently without having to change anything. So in the end of this configuration, I expect to be able to type wget google.com, not wget localhost or wget 192.168.0.1, which is my own ip.
– rogerJ
Mar 1 '16 at 17:06
|
show 1 more comment
I was struggling with this issue on Ubuntu 14.04 (I tried both GatewayPorts clientspecified
and GatewayPorts yes
in /etc/ssh/sshd_config
).
Instead, adding this to my sshd_config
worked:
Match User !root
GatewayPorts yes
That is, I had to specify a user to match the rule to.
add a comment |
I was struggling with this issue on Ubuntu 14.04 (I tried both GatewayPorts clientspecified
and GatewayPorts yes
in /etc/ssh/sshd_config
).
Instead, adding this to my sshd_config
worked:
Match User !root
GatewayPorts yes
That is, I had to specify a user to match the rule to.
add a comment |
I was struggling with this issue on Ubuntu 14.04 (I tried both GatewayPorts clientspecified
and GatewayPorts yes
in /etc/ssh/sshd_config
).
Instead, adding this to my sshd_config
worked:
Match User !root
GatewayPorts yes
That is, I had to specify a user to match the rule to.
I was struggling with this issue on Ubuntu 14.04 (I tried both GatewayPorts clientspecified
and GatewayPorts yes
in /etc/ssh/sshd_config
).
Instead, adding this to my sshd_config
worked:
Match User !root
GatewayPorts yes
That is, I had to specify a user to match the rule to.
answered Mar 8 '16 at 19:12
frnsysfrnsys
1012
1012
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f266772%2fssh-reverse-tunnel-with-remote-ip%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
1
superuser.com/questions/661772/iptables-redirect-to-localhost
– 7171u
Mar 1 '16 at 14:04
@7171u ok thanks, I have added a rule so that iptables -t nat -L shows: DNAT tcp -- anywhere 192.168.0.2 tcp dpt:http to:127.0.0.1:80 however, the second wget is still not working, what could be wrong?
– rogerJ
Mar 1 '16 at 14:32
I have used this on RHEL7 and it works fine.
– 7171u
Mar 1 '16 at 15:01