lockout local logins on reverse-ssh appliance

The name of the pictureThe name of the pictureThe name of the pictureClash 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.










share|improve this question























  • 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














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.










share|improve this question























  • 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












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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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
















  • 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










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 :) )






share|improve this answer






















  • @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

















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.






share|improve this answer




















  • 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











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
);



);













draft saved

draft discarded


















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 :) )






share|improve this answer






















  • @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














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 :) )






share|improve this answer






















  • @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












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 :) )






share|improve this answer














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 :) )







share|improve this answer














share|improve this answer



share|improve this answer








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
















  • @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












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.






share|improve this answer




















  • 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















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.






share|improve this answer




















  • 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













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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










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 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

















  • 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
















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


















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay