lockout local logins on reverse-ssh appliance
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I have set up a reverse-ssh appliance with a Raspberry-Pi for use at a customer site to connect to a piece of equipment I have to support via a USB-to-RS232 adapter. I've cleared this with the customer's IT staff, and the appliance is already configured, tested and working fine.
But in the interest of hardening it from local-net access, I would like to restrict logins to only allow login through the reverse SSH tunnel, and not allow anyone on the local customer's network to login.
The outgoing reverse-ssh connection uses a 4096-bit keyfile with no password to connect to the server, but I still see a user/password prompt when I connect back from the server to the Pi through the reverse ssh connection. That's not a problem for me, but I was just concerned about limiting the ability of anyone locally to log in with a local telnet or ssh. I already have a good password on the only active account, so I doubt that anyone would manage to log in anyway.
It would be good if it still allowed logins on the local machine with an attached USB keyboard for maintenance purposes, but that's not mandatory. The device is inside a locked metal enclosure in a locked room, so unauthorized physical access is not a great concern. I just want to lock out local-network access to telnet & ssh logins while still allowing ssh logins through the reverse ssh tunnel.
ssh networking security raspberry-pi ssh-tunneling
add a comment |
up vote
2
down vote
favorite
I have set up a reverse-ssh appliance with a Raspberry-Pi for use at a customer site to connect to a piece of equipment I have to support via a USB-to-RS232 adapter. I've cleared this with the customer's IT staff, and the appliance is already configured, tested and working fine.
But in the interest of hardening it from local-net access, I would like to restrict logins to only allow login through the reverse SSH tunnel, and not allow anyone on the local customer's network to login.
The outgoing reverse-ssh connection uses a 4096-bit keyfile with no password to connect to the server, but I still see a user/password prompt when I connect back from the server to the Pi through the reverse ssh connection. That's not a problem for me, but I was just concerned about limiting the ability of anyone locally to log in with a local telnet or ssh. I already have a good password on the only active account, so I doubt that anyone would manage to log in anyway.
It would be good if it still allowed logins on the local machine with an attached USB keyboard for maintenance purposes, but that's not mandatory. The device is inside a locked metal enclosure in a locked room, so unauthorized physical access is not a great concern. I just want to lock out local-network access to telnet & ssh logins while still allowing ssh logins through the reverse ssh tunnel.
ssh networking security raspberry-pi ssh-tunneling
Wait, I'm a little confused by what you mean by reverse-ssh connection. Is the RPi actively connecting to the server and performing a reverse tunnel (ssh -R
) or is the server connecting to the RPi and then tunneling the port (ssh -L
). In other words, the "outgoing" connection is RPi->server or server->RPi?
– grochmal
Aug 22 '16 at 1:30
It is running ssh -R - reverse tunnel.
– Shay Walters
Aug 22 '16 at 2:30
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I have set up a reverse-ssh appliance with a Raspberry-Pi for use at a customer site to connect to a piece of equipment I have to support via a USB-to-RS232 adapter. I've cleared this with the customer's IT staff, and the appliance is already configured, tested and working fine.
But in the interest of hardening it from local-net access, I would like to restrict logins to only allow login through the reverse SSH tunnel, and not allow anyone on the local customer's network to login.
The outgoing reverse-ssh connection uses a 4096-bit keyfile with no password to connect to the server, but I still see a user/password prompt when I connect back from the server to the Pi through the reverse ssh connection. That's not a problem for me, but I was just concerned about limiting the ability of anyone locally to log in with a local telnet or ssh. I already have a good password on the only active account, so I doubt that anyone would manage to log in anyway.
It would be good if it still allowed logins on the local machine with an attached USB keyboard for maintenance purposes, but that's not mandatory. The device is inside a locked metal enclosure in a locked room, so unauthorized physical access is not a great concern. I just want to lock out local-network access to telnet & ssh logins while still allowing ssh logins through the reverse ssh tunnel.
ssh networking security raspberry-pi ssh-tunneling
I have set up a reverse-ssh appliance with a Raspberry-Pi for use at a customer site to connect to a piece of equipment I have to support via a USB-to-RS232 adapter. I've cleared this with the customer's IT staff, and the appliance is already configured, tested and working fine.
But in the interest of hardening it from local-net access, I would like to restrict logins to only allow login through the reverse SSH tunnel, and not allow anyone on the local customer's network to login.
The outgoing reverse-ssh connection uses a 4096-bit keyfile with no password to connect to the server, but I still see a user/password prompt when I connect back from the server to the Pi through the reverse ssh connection. That's not a problem for me, but I was just concerned about limiting the ability of anyone locally to log in with a local telnet or ssh. I already have a good password on the only active account, so I doubt that anyone would manage to log in anyway.
It would be good if it still allowed logins on the local machine with an attached USB keyboard for maintenance purposes, but that's not mandatory. The device is inside a locked metal enclosure in a locked room, so unauthorized physical access is not a great concern. I just want to lock out local-network access to telnet & ssh logins while still allowing ssh logins through the reverse ssh tunnel.
ssh networking security raspberry-pi ssh-tunneling
ssh networking security raspberry-pi ssh-tunneling
edited Dec 5 at 13:24
Jeff Schaller
37.8k1053123
37.8k1053123
asked Aug 21 '16 at 19:22
Shay Walters
435
435
Wait, I'm a little confused by what you mean by reverse-ssh connection. Is the RPi actively connecting to the server and performing a reverse tunnel (ssh -R
) or is the server connecting to the RPi and then tunneling the port (ssh -L
). In other words, the "outgoing" connection is RPi->server or server->RPi?
– grochmal
Aug 22 '16 at 1:30
It is running ssh -R - reverse tunnel.
– Shay Walters
Aug 22 '16 at 2:30
add a comment |
Wait, I'm a little confused by what you mean by reverse-ssh connection. Is the RPi actively connecting to the server and performing a reverse tunnel (ssh -R
) or is the server connecting to the RPi and then tunneling the port (ssh -L
). In other words, the "outgoing" connection is RPi->server or server->RPi?
– grochmal
Aug 22 '16 at 1:30
It is running ssh -R - reverse tunnel.
– Shay Walters
Aug 22 '16 at 2:30
Wait, I'm a little confused by what you mean by reverse-ssh connection. Is the RPi actively connecting to the server and performing a reverse tunnel (
ssh -R
) or is the server connecting to the RPi and then tunneling the port (ssh -L
). In other words, the "outgoing" connection is RPi->server or server->RPi?– grochmal
Aug 22 '16 at 1:30
Wait, I'm a little confused by what you mean by reverse-ssh connection. Is the RPi actively connecting to the server and performing a reverse tunnel (
ssh -R
) or is the server connecting to the RPi and then tunneling the port (ssh -L
). In other words, the "outgoing" connection is RPi->server or server->RPi?– grochmal
Aug 22 '16 at 1:30
It is running ssh -R - reverse tunnel.
– Shay Walters
Aug 22 '16 at 2:30
It is running ssh -R - reverse tunnel.
– Shay Walters
Aug 22 '16 at 2:30
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
accepted
Since it it that RPi that is connecting to the server and then creating a reverse SSH tunnel, you can run sshd
on localhost on the RPi.
First of all add a bind_address
to the reverse tunnel command, i.e. perform the ssh
call from the RPi to the server as:
ssh -R localhost:6060:localhost:22 -i path/to/key me@server
Yes, that is localhost
two times:
localhost:22
is where the traffic is redirected on the RPi.localhost:6060
is the port that will listen on the server (you may or may not wish this to be on localhost, since the server is available from the internet you probably what this to be localhost).
Now, on the RPi you can add to /etc/ssh/sshd_config
the following:
ListenAddress 127.0.0.1
And restart sshd
.
Now the RPi will reject connections on the local network to port 22 because the socket is bound to localhost
(on loopback, a different interface from the one with the local IP), yet it will answer the reverse SSH tunnel because that socket explicitly binds to localhost
on the RPi's side of the tunnel.
ssh -p 6060 user@rpi
Will connect from the server to the RPi as normal.
Note: This may be dangerous, since there is no easy way to make the RPi answer to connections from the local network again. The only way to fix things if something breaks very badly is to go there and connect a screen and a keyboard. Seriously, test it first, if you make a typo somewhere you will need physical access.
Note 2: The only real difference between this solution an Stephen Harris' one is that the RPi will now reject connections to port 22. Whether you want that or want it to accept the connections and just reject the authorisation, is a matter of preference (or honeypot design :) )
@stephen-harris also - Thanks for some very informative answers. I really appreciate the explanations. Those will let me feel more secure against some opportune hacker.
– Shay Walters
Aug 22 '16 at 23:00
add a comment |
up vote
1
down vote
For your RPi's ssh
daemon, look at sshd_config
and the AllowUsers
option. You can specify hostnames in that.
Since you're reverse tunnelling then it's possible that the connection is from localhost
and so
AllowUsers yourusername@localhost
in /etc/ssh/sshd_config
(or wherever your OS puts it) might be sufficient. Remember to restart sshd
(or just SIGHUP it) after changing sshd_config
.
Since you're only touching sshd
then serial console logins won't be impacted.
yes, when I connect back through the reverse tunnel, it shows up as localhost. I was wanting to know if there's a way to restrict any other logins that don't come through that reverse tunnel, so that if someone stumbles across the local net (192.168.x.x) IP address, that they would be unable to login. But I suppose that if someone manages to login, they're going to be coming from localhost, too. I'm just looking to cover my bases so that even if someone discovers an exploit that gets them logged in, I could limit the extent of the breach.
– Shay Walters
Aug 22 '16 at 2:35
If someone doesn't come from the tunnel then it'll show as coming from their remote IP address (eg 10.20.30.40) and so theAllowUsers
rule will block it. Only ssh connections originating from the machine (eg people already logged in, or from the tunnel) will originate fromlocalhost
. The address in the restriction is the remote address the login originates from.
– Stephen Harris
Aug 22 '16 at 2:45
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',
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%2f304850%2flockout-local-logins-on-reverse-ssh-appliance%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
up vote
0
down vote
accepted
Since it it that RPi that is connecting to the server and then creating a reverse SSH tunnel, you can run sshd
on localhost on the RPi.
First of all add a bind_address
to the reverse tunnel command, i.e. perform the ssh
call from the RPi to the server as:
ssh -R localhost:6060:localhost:22 -i path/to/key me@server
Yes, that is localhost
two times:
localhost:22
is where the traffic is redirected on the RPi.localhost:6060
is the port that will listen on the server (you may or may not wish this to be on localhost, since the server is available from the internet you probably what this to be localhost).
Now, on the RPi you can add to /etc/ssh/sshd_config
the following:
ListenAddress 127.0.0.1
And restart sshd
.
Now the RPi will reject connections on the local network to port 22 because the socket is bound to localhost
(on loopback, a different interface from the one with the local IP), yet it will answer the reverse SSH tunnel because that socket explicitly binds to localhost
on the RPi's side of the tunnel.
ssh -p 6060 user@rpi
Will connect from the server to the RPi as normal.
Note: This may be dangerous, since there is no easy way to make the RPi answer to connections from the local network again. The only way to fix things if something breaks very badly is to go there and connect a screen and a keyboard. Seriously, test it first, if you make a typo somewhere you will need physical access.
Note 2: The only real difference between this solution an Stephen Harris' one is that the RPi will now reject connections to port 22. Whether you want that or want it to accept the connections and just reject the authorisation, is a matter of preference (or honeypot design :) )
@stephen-harris also - Thanks for some very informative answers. I really appreciate the explanations. Those will let me feel more secure against some opportune hacker.
– Shay Walters
Aug 22 '16 at 23:00
add a comment |
up vote
0
down vote
accepted
Since it it that RPi that is connecting to the server and then creating a reverse SSH tunnel, you can run sshd
on localhost on the RPi.
First of all add a bind_address
to the reverse tunnel command, i.e. perform the ssh
call from the RPi to the server as:
ssh -R localhost:6060:localhost:22 -i path/to/key me@server
Yes, that is localhost
two times:
localhost:22
is where the traffic is redirected on the RPi.localhost:6060
is the port that will listen on the server (you may or may not wish this to be on localhost, since the server is available from the internet you probably what this to be localhost).
Now, on the RPi you can add to /etc/ssh/sshd_config
the following:
ListenAddress 127.0.0.1
And restart sshd
.
Now the RPi will reject connections on the local network to port 22 because the socket is bound to localhost
(on loopback, a different interface from the one with the local IP), yet it will answer the reverse SSH tunnel because that socket explicitly binds to localhost
on the RPi's side of the tunnel.
ssh -p 6060 user@rpi
Will connect from the server to the RPi as normal.
Note: This may be dangerous, since there is no easy way to make the RPi answer to connections from the local network again. The only way to fix things if something breaks very badly is to go there and connect a screen and a keyboard. Seriously, test it first, if you make a typo somewhere you will need physical access.
Note 2: The only real difference between this solution an Stephen Harris' one is that the RPi will now reject connections to port 22. Whether you want that or want it to accept the connections and just reject the authorisation, is a matter of preference (or honeypot design :) )
@stephen-harris also - Thanks for some very informative answers. I really appreciate the explanations. Those will let me feel more secure against some opportune hacker.
– Shay Walters
Aug 22 '16 at 23:00
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
Since it it that RPi that is connecting to the server and then creating a reverse SSH tunnel, you can run sshd
on localhost on the RPi.
First of all add a bind_address
to the reverse tunnel command, i.e. perform the ssh
call from the RPi to the server as:
ssh -R localhost:6060:localhost:22 -i path/to/key me@server
Yes, that is localhost
two times:
localhost:22
is where the traffic is redirected on the RPi.localhost:6060
is the port that will listen on the server (you may or may not wish this to be on localhost, since the server is available from the internet you probably what this to be localhost).
Now, on the RPi you can add to /etc/ssh/sshd_config
the following:
ListenAddress 127.0.0.1
And restart sshd
.
Now the RPi will reject connections on the local network to port 22 because the socket is bound to localhost
(on loopback, a different interface from the one with the local IP), yet it will answer the reverse SSH tunnel because that socket explicitly binds to localhost
on the RPi's side of the tunnel.
ssh -p 6060 user@rpi
Will connect from the server to the RPi as normal.
Note: This may be dangerous, since there is no easy way to make the RPi answer to connections from the local network again. The only way to fix things if something breaks very badly is to go there and connect a screen and a keyboard. Seriously, test it first, if you make a typo somewhere you will need physical access.
Note 2: The only real difference between this solution an Stephen Harris' one is that the RPi will now reject connections to port 22. Whether you want that or want it to accept the connections and just reject the authorisation, is a matter of preference (or honeypot design :) )
Since it it that RPi that is connecting to the server and then creating a reverse SSH tunnel, you can run sshd
on localhost on the RPi.
First of all add a bind_address
to the reverse tunnel command, i.e. perform the ssh
call from the RPi to the server as:
ssh -R localhost:6060:localhost:22 -i path/to/key me@server
Yes, that is localhost
two times:
localhost:22
is where the traffic is redirected on the RPi.localhost:6060
is the port that will listen on the server (you may or may not wish this to be on localhost, since the server is available from the internet you probably what this to be localhost).
Now, on the RPi you can add to /etc/ssh/sshd_config
the following:
ListenAddress 127.0.0.1
And restart sshd
.
Now the RPi will reject connections on the local network to port 22 because the socket is bound to localhost
(on loopback, a different interface from the one with the local IP), yet it will answer the reverse SSH tunnel because that socket explicitly binds to localhost
on the RPi's side of the tunnel.
ssh -p 6060 user@rpi
Will connect from the server to the RPi as normal.
Note: This may be dangerous, since there is no easy way to make the RPi answer to connections from the local network again. The only way to fix things if something breaks very badly is to go there and connect a screen and a keyboard. Seriously, test it first, if you make a typo somewhere you will need physical access.
Note 2: The only real difference between this solution an Stephen Harris' one is that the RPi will now reject connections to port 22. Whether you want that or want it to accept the connections and just reject the authorisation, is a matter of preference (or honeypot design :) )
edited Aug 22 '16 at 3:18
answered Aug 22 '16 at 3:04
grochmal
5,66131544
5,66131544
@stephen-harris also - Thanks for some very informative answers. I really appreciate the explanations. Those will let me feel more secure against some opportune hacker.
– Shay Walters
Aug 22 '16 at 23:00
add a comment |
@stephen-harris also - Thanks for some very informative answers. I really appreciate the explanations. Those will let me feel more secure against some opportune hacker.
– Shay Walters
Aug 22 '16 at 23:00
@stephen-harris also - Thanks for some very informative answers. I really appreciate the explanations. Those will let me feel more secure against some opportune hacker.
– Shay Walters
Aug 22 '16 at 23:00
@stephen-harris also - Thanks for some very informative answers. I really appreciate the explanations. Those will let me feel more secure against some opportune hacker.
– Shay Walters
Aug 22 '16 at 23:00
add a comment |
up vote
1
down vote
For your RPi's ssh
daemon, look at sshd_config
and the AllowUsers
option. You can specify hostnames in that.
Since you're reverse tunnelling then it's possible that the connection is from localhost
and so
AllowUsers yourusername@localhost
in /etc/ssh/sshd_config
(or wherever your OS puts it) might be sufficient. Remember to restart sshd
(or just SIGHUP it) after changing sshd_config
.
Since you're only touching sshd
then serial console logins won't be impacted.
yes, when I connect back through the reverse tunnel, it shows up as localhost. I was wanting to know if there's a way to restrict any other logins that don't come through that reverse tunnel, so that if someone stumbles across the local net (192.168.x.x) IP address, that they would be unable to login. But I suppose that if someone manages to login, they're going to be coming from localhost, too. I'm just looking to cover my bases so that even if someone discovers an exploit that gets them logged in, I could limit the extent of the breach.
– Shay Walters
Aug 22 '16 at 2:35
If someone doesn't come from the tunnel then it'll show as coming from their remote IP address (eg 10.20.30.40) and so theAllowUsers
rule will block it. Only ssh connections originating from the machine (eg people already logged in, or from the tunnel) will originate fromlocalhost
. The address in the restriction is the remote address the login originates from.
– Stephen Harris
Aug 22 '16 at 2:45
add a comment |
up vote
1
down vote
For your RPi's ssh
daemon, look at sshd_config
and the AllowUsers
option. You can specify hostnames in that.
Since you're reverse tunnelling then it's possible that the connection is from localhost
and so
AllowUsers yourusername@localhost
in /etc/ssh/sshd_config
(or wherever your OS puts it) might be sufficient. Remember to restart sshd
(or just SIGHUP it) after changing sshd_config
.
Since you're only touching sshd
then serial console logins won't be impacted.
yes, when I connect back through the reverse tunnel, it shows up as localhost. I was wanting to know if there's a way to restrict any other logins that don't come through that reverse tunnel, so that if someone stumbles across the local net (192.168.x.x) IP address, that they would be unable to login. But I suppose that if someone manages to login, they're going to be coming from localhost, too. I'm just looking to cover my bases so that even if someone discovers an exploit that gets them logged in, I could limit the extent of the breach.
– Shay Walters
Aug 22 '16 at 2:35
If someone doesn't come from the tunnel then it'll show as coming from their remote IP address (eg 10.20.30.40) and so theAllowUsers
rule will block it. Only ssh connections originating from the machine (eg people already logged in, or from the tunnel) will originate fromlocalhost
. The address in the restriction is the remote address the login originates from.
– Stephen Harris
Aug 22 '16 at 2:45
add a comment |
up vote
1
down vote
up vote
1
down vote
For your RPi's ssh
daemon, look at sshd_config
and the AllowUsers
option. You can specify hostnames in that.
Since you're reverse tunnelling then it's possible that the connection is from localhost
and so
AllowUsers yourusername@localhost
in /etc/ssh/sshd_config
(or wherever your OS puts it) might be sufficient. Remember to restart sshd
(or just SIGHUP it) after changing sshd_config
.
Since you're only touching sshd
then serial console logins won't be impacted.
For your RPi's ssh
daemon, look at sshd_config
and the AllowUsers
option. You can specify hostnames in that.
Since you're reverse tunnelling then it's possible that the connection is from localhost
and so
AllowUsers yourusername@localhost
in /etc/ssh/sshd_config
(or wherever your OS puts it) might be sufficient. Remember to restart sshd
(or just SIGHUP it) after changing sshd_config
.
Since you're only touching sshd
then serial console logins won't be impacted.
answered Aug 21 '16 at 19:44
Stephen Harris
24.1k24477
24.1k24477
yes, when I connect back through the reverse tunnel, it shows up as localhost. I was wanting to know if there's a way to restrict any other logins that don't come through that reverse tunnel, so that if someone stumbles across the local net (192.168.x.x) IP address, that they would be unable to login. But I suppose that if someone manages to login, they're going to be coming from localhost, too. I'm just looking to cover my bases so that even if someone discovers an exploit that gets them logged in, I could limit the extent of the breach.
– Shay Walters
Aug 22 '16 at 2:35
If someone doesn't come from the tunnel then it'll show as coming from their remote IP address (eg 10.20.30.40) and so theAllowUsers
rule will block it. Only ssh connections originating from the machine (eg people already logged in, or from the tunnel) will originate fromlocalhost
. The address in the restriction is the remote address the login originates from.
– Stephen Harris
Aug 22 '16 at 2:45
add a comment |
yes, when I connect back through the reverse tunnel, it shows up as localhost. I was wanting to know if there's a way to restrict any other logins that don't come through that reverse tunnel, so that if someone stumbles across the local net (192.168.x.x) IP address, that they would be unable to login. But I suppose that if someone manages to login, they're going to be coming from localhost, too. I'm just looking to cover my bases so that even if someone discovers an exploit that gets them logged in, I could limit the extent of the breach.
– Shay Walters
Aug 22 '16 at 2:35
If someone doesn't come from the tunnel then it'll show as coming from their remote IP address (eg 10.20.30.40) and so theAllowUsers
rule will block it. Only ssh connections originating from the machine (eg people already logged in, or from the tunnel) will originate fromlocalhost
. The address in the restriction is the remote address the login originates from.
– Stephen Harris
Aug 22 '16 at 2:45
yes, when I connect back through the reverse tunnel, it shows up as localhost. I was wanting to know if there's a way to restrict any other logins that don't come through that reverse tunnel, so that if someone stumbles across the local net (192.168.x.x) IP address, that they would be unable to login. But I suppose that if someone manages to login, they're going to be coming from localhost, too. I'm just looking to cover my bases so that even if someone discovers an exploit that gets them logged in, I could limit the extent of the breach.
– Shay Walters
Aug 22 '16 at 2:35
yes, when I connect back through the reverse tunnel, it shows up as localhost. I was wanting to know if there's a way to restrict any other logins that don't come through that reverse tunnel, so that if someone stumbles across the local net (192.168.x.x) IP address, that they would be unable to login. But I suppose that if someone manages to login, they're going to be coming from localhost, too. I'm just looking to cover my bases so that even if someone discovers an exploit that gets them logged in, I could limit the extent of the breach.
– Shay Walters
Aug 22 '16 at 2:35
If someone doesn't come from the tunnel then it'll show as coming from their remote IP address (eg 10.20.30.40) and so the
AllowUsers
rule will block it. Only ssh connections originating from the machine (eg people already logged in, or from the tunnel) will originate from localhost
. The address in the restriction is the remote address the login originates from.– Stephen Harris
Aug 22 '16 at 2:45
If someone doesn't come from the tunnel then it'll show as coming from their remote IP address (eg 10.20.30.40) and so the
AllowUsers
rule will block it. Only ssh connections originating from the machine (eg people already logged in, or from the tunnel) will originate from localhost
. The address in the restriction is the remote address the login originates from.– Stephen Harris
Aug 22 '16 at 2:45
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.
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%2funix.stackexchange.com%2fquestions%2f304850%2flockout-local-logins-on-reverse-ssh-appliance%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
Wait, I'm a little confused by what you mean by reverse-ssh connection. Is the RPi actively connecting to the server and performing a reverse tunnel (
ssh -R
) or is the server connecting to the RPi and then tunneling the port (ssh -L
). In other words, the "outgoing" connection is RPi->server or server->RPi?– grochmal
Aug 22 '16 at 1:30
It is running ssh -R - reverse tunnel.
– Shay Walters
Aug 22 '16 at 2:30