How to limit passwordless ssh login to allow only outgoing tunnel? Possible?
If I want to do something like:- ssh -R 12345:localhost:80 -N chris@mycomputer.com from a remote machine with a passwordless login is there any way I can make it so that the *only* thing allowed from the remote machine is the ssh tunnel? I want to be able to see the apache web server running on the remote computer from my home machine. The remote computer may have occasional reboots/upgrades etc. so it needs a passwordless login to be able to reconnect the ssh tunnel. At present I don't allow passwordless (i.e. public key with no passphrase) logins and I don't want to allow them unless I can, as stated above, somehow allow ssh to only be used to create a tunnel. -- Chris Green
On Wed, 3 Oct 2012 19:49:27 +0100, cl@isbd.net said:
At present I don't allow passwordless (i.e. public key with no passphrase) logins
You can't stop them. There is no way, from the server, to ascertain whether or not the key being used to authenticate has been protected by a passphrase because that is decrypted on the sending system, not the receiving one. -- We're looking for smart Linux people: http://www.tiger-computing.co.uk/jobs
On Wed, Oct 03, 2012 at 08:07:21PM +0100, Keith Edmunds wrote:
On Wed, 3 Oct 2012 19:49:27 +0100, cl@isbd.net said:
At present I don't allow passwordless (i.e. public key with no passphrase) logins
You can't stop them. There is no way, from the server, to ascertain whether or not the key being used to authenticate has been protected by a passphrase because that is decrypted on the sending system, not the receiving one.
Yes, but if the key isn't installed on the server then it's not going to work is it! I.e. it's down to me (as it's my server) to decide what keys to install, and if all the keys have passphrases then you need to know the passphrase to get the key to log in. -- Chris Green
On 04/10/2012 09:59, Chris Green wrote:
On Wed, Oct 03, 2012 at 08:07:21PM +0100, Keith Edmunds wrote:
On Wed, 3 Oct 2012 19:49:27 +0100, cl@isbd.net said:
At present I don't allow passwordless (i.e. public key with no passphrase) logins
You can't stop them. There is no way, from the server, to ascertain whether or not the key being used to authenticate has been protected by a passphrase because that is decrypted on the sending system, not the receiving one.
Yes, but if the key isn't installed on the server then it's not going to work is it! I.e. it's down to me (as it's my server) to decide what keys to install, and if all the keys have passphrases then you need to know the passphrase to get the key to log in.
It doesn't work that way, Chris. The password is entered at the client end, as in, remote from the server. All the server does is ascertain that it's the correct certificate. It has no way of knowing whether it had a passphrase or not. As I said earlier. it's not terribly clear what you're trying to achieve here... Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com ---------------------------------------------------------------------
On Thu, Oct 04, 2012 at 10:30:09AM +0100, Laurie Brown wrote:
On 04/10/2012 09:59, Chris Green wrote:
On Wed, Oct 03, 2012 at 08:07:21PM +0100, Keith Edmunds wrote:
On Wed, 3 Oct 2012 19:49:27 +0100, cl@isbd.net said:
At present I don't allow passwordless (i.e. public key with no passphrase) logins
You can't stop them. There is no way, from the server, to ascertain whether or not the key being used to authenticate has been protected by a passphrase because that is decrypted on the sending system, not the receiving one.
Yes, but if the key isn't installed on the server then it's not going to work is it! I.e. it's down to me (as it's my server) to decide what keys to install, and if all the keys have passphrases then you need to know the passphrase to get the key to log in.
It doesn't work that way, Chris. The password is entered at the client end, as in, remote from the server. All the server does is ascertain that it's the correct certificate. It has no way of knowing whether it had a passphrase or not.
Yes, sorry, I am the client as well as it being my server. So it's up to me (as client) whether to give a passphrase to the key or not.
As I said earlier. it's not terribly clear what you're trying to achieve here...
See my much longer reply. -- Chris Green
On 4 October 2012 10:46, Chris Green <cl@isbd.net> wrote:
On Thu, Oct 04, 2012 at 10:30:09AM +0100, Laurie Brown wrote:
On 04/10/2012 09:59, Chris Green wrote:
On Wed, Oct 03, 2012 at 08:07:21PM +0100, Keith Edmunds wrote:
On Wed, 3 Oct 2012 19:49:27 +0100, cl@isbd.net said:
At present I don't allow passwordless (i.e. public key with no passphrase) logins
You can't stop them. There is no way, from the server, to ascertain whether or not the key being used to authenticate has been protected by a passphrase because that is decrypted on the sending system, not the receiving one.
Yes, but if the key isn't installed on the server then it's not going to work is it! I.e. it's down to me (as it's my server) to decide what keys to install, and if all the keys have passphrases then you need to know the passphrase to get the key to log in.
It doesn't work that way, Chris. The password is entered at the client end, as in, remote from the server. All the server does is ascertain that it's the correct certificate. It has no way of knowing whether it had a passphrase or not.
Yes, sorry, I am the client as well as it being my server. So it's up to me (as client) whether to give a passphrase to the key or not.
As I said earlier. it's not terribly clear what you're trying to achieve here...
See my much longer reply.
Will ssh-agent do what you need? It works per session so if you stay logged in I *think* it will do what you need - if I understand you correctly. -- "None are more hopelessly enslaved than those who falsely believe they are free" -- Johann Wolfgang von Goethe
On 03/10/2012 19:49, Chris Green wrote:
If I want to do something like:-
ssh -R 12345:localhost:80 -N chris@mycomputer.com
from a remote machine with a passwordless login is there any way I can make it so that the *only* thing allowed from the remote machine is the ssh tunnel?
I want to be able to see the apache web server running on the remote computer from my home machine. The remote computer may have occasional reboots/upgrades etc. so it needs a passwordless login to be able to reconnect the ssh tunnel. At present I don't allow passwordless (i.e. public key with no passphrase) logins and I don't want to allow them unless I can, as stated above, somehow allow ssh to only be used to create a tunnel.
I'm not sure I fully understand what you're trying to achieve, but it seems that you want to limit access to SSH by initiating the connections at the remote end. As Keith says, once the certificate is "live" there's no way to tell if it's passwordless or otherwise. That said, I think he, and I, have got the wrong end of the stick and assumed that by password-less login you mean via certificates and passwords. That's not at all clear... It's very common to set up SSH so that interactive user name login, with a password or not, is impossible, but is only possible with a certificate pair (validated on the connecting machine by password) and is a basic level of security for SSH everyone should use. The following page is a clear example of how to do this: http://en.gentoo-wiki.com/wiki/SSH_Public_Key_Authentication What you could try, if as I suspect, you wish to limit access to the remote machine, is to use port-knocking and iptables to open the tunnel up, AND use certificate pairs. http://en.gentoo-wiki.com/wiki/Port_Knocking http://www.hostsvault.com/blog/howto-protect-services-like-ssh-against-brute... http://www.soloport.com/iptables.html I'm a big fan of Shorewall, so: http://www.shorewall.net/3.0/PortKnocking.html HtH. Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com ---------------------------------------------------------------------
On Thu, Oct 04, 2012 at 09:50:04AM +0100, Laurie Brown wrote:
On 03/10/2012 19:49, Chris Green wrote:
If I want to do something like:-
ssh -R 12345:localhost:80 -N chris@mycomputer.com
from a remote machine with a passwordless login is there any way I can make it so that the *only* thing allowed from the remote machine is the ssh tunnel?
I want to be able to see the apache web server running on the remote computer from my home machine. The remote computer may have occasional reboots/upgrades etc. so it needs a passwordless login to be able to reconnect the ssh tunnel. At present I don't allow passwordless (i.e. public key with no passphrase) logins and I don't want to allow them unless I can, as stated above, somehow allow ssh to only be used to create a tunnel.
I'm not sure I fully understand what you're trying to achieve, but it seems that you want to limit access to SSH by initiating the connections at the remote end. As Keith says, once the certificate is "live" there's no way to tell if it's passwordless or otherwise. That said, I think he, and I, have got the wrong end of the stick and assumed that by password-less login you mean via certificates and passwords. That's not at all clear...
Sorry, maybe I wasn't clear. The *only* person who has logins my machine (from remote systems) is me, so it's only me that is creating keys etc. for logins. At present my firewall only allows ssh connections (port 22) from two specific IP addresses (hosting services where I have ssh access) and requires a password (not public key) for authentication. Thus, to break in, someone needs two passwords and the knowledge of the route to be taken to log in. I want to get access (for me only) to an apache server running on our boat in France. The system on the boat has a good WiFi connection. It already runs an ssh connection like:- ssh -R 12345:localhost:80 -N chris@mycomputer.com to one of the hosting services where I have ssh access, this allows me to connect through the ssh tunnel to the system on the boat and I can update it, configure it, etc. using the command line from here at home. The ssh from the boat system to the hosting server uses a public-key with no passphrase so it's "passwordless" and if/when the system on the boat gets restarted for whatever reason it can reconnect successfully. What I want to do is to run a similar ssh tunnelling command from the system on the boat to my system at home, it needs to be public-key with no passphrase but I don't want it to provide any sort of access from outside, I just want to be able to reverse tunnel down the connection to access port 80 on the system on the boat. I have already confirimed that it works using two hops as for my ssh command line access. However I'd like to make it easier to use so that I can just click on a link in my browser and just see what's happening on the boat. Thus I want to have the sshd on my desktop box only allow a remote make the ssh tunnel and nothing else. -- Chris Green
On Thu, 4 Oct 2012 10:44:57 +0100, cl@isbd.net said:
I don't want it to provide any sort of access from outside, I just want to be able to reverse tunnel down the connection to access port 80 on the system on the boat.
In my opinion, you are making life unnecessarily complicated for yourself. The easy way to do this is to set up a VPN (OpenVPN is reasonably straightforward) from the boat to wherever you want, using multiple VPN connections if necessary. Then you can firewall incoming connections over the VPN to allow access from only those places you specify. That would be a lot more secure, and, once set up, somewhat easier to manage. -- We're looking for smart Linux people: http://www.tiger-computing.co.uk/jobs
On 04/10/2012 20:38, Keith Edmunds wrote:
On Thu, 4 Oct 2012 10:44:57 +0100, cl@isbd.net said:
I don't want it to provide any sort of access from outside, I just want to be able to reverse tunnel down the connection to access port 80 on the system on the boat.
In my opinion, you are making life unnecessarily complicated for yourself. The easy way to do this is to set up a VPN (OpenVPN is reasonably straightforward) from the boat to wherever you want, using multiple VPN connections if necessary. Then you can firewall incoming connections over the VPN to allow access from only those places you specify.
That would be a lot more secure, and, once set up, somewhat easier to manage.
I entirely agree. The combination of Shorewall and OpenVPN is pretty hard to beat, IMO. Also, assuming your web pages aren't too heavy on graphics, how about using links in an SSH session direct to localhost? Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com ---------------------------------------------------------------------
On Fri, Oct 05, 2012 at 11:16:38AM +0100, Laurie Brown wrote:
On 04/10/2012 20:38, Keith Edmunds wrote:
On Thu, 4 Oct 2012 10:44:57 +0100, cl@isbd.net said:
I don't want it to provide any sort of access from outside, I just want to be able to reverse tunnel down the connection to access port 80 on the system on the boat.
In my opinion, you are making life unnecessarily complicated for yourself. The easy way to do this is to set up a VPN (OpenVPN is reasonably straightforward) from the boat to wherever you want, using multiple VPN connections if necessary. Then you can firewall incoming connections over the VPN to allow access from only those places you specify.
That would be a lot more secure, and, once set up, somewhat easier to manage.
I entirely agree. The combination of Shorewall and OpenVPN is pretty hard to beat, IMO.
Also, assuming your web pages aren't too heavy on graphics, how about using links in an SSH session direct to localhost?
I'm not sure if you've quite understood the set-up still. The system on the boat running the apache web server (which I want to access from here at home) is a very basic server system running on a 2Gb (disk that is) eeePc with no GUI and not a lot of spare space. This is connected to the internet via a WiFi service at the place where the boat is moored, thus it's behind a NAT (presumably) firewall and cannot be accessed directly from the Internet. I already have autossh running ssh connections out from the eeePc on the boat to my hosting service shell account. Thus to get command line access to the eeePc I can login to the hosting service shell account and ssh to the eeePc from there. As I said before the reason for going via the shell hosting service is that it means my home system's firewall only needs to open up port 22 to a couple of specific IP addresses and somoene getting access to the eeePc on the boat wouldn't be able to access my home PC without breaking the ssh passwords on the home PC. What I now want to do in addition is make it easier to access the eeePc's web server from home without (seriously) impairing the existing security. I can already do this if I run another ssh tunnel out from the boat eeePc (exporting port 80) and then a further one from the hosting shell account to my home PC, but as I don't want any password/passphraseless access to my home PC this involves manually logging into the hosting shell, starting up the ssh tunnel (giving it my password) and then connecting my browser to the boat. I want to make this easier. -- Chris Green
On 05/10/2012 11:43, Chris Green wrote: [SNIP]
is moored, thus it's behind a NAT (presumably) firewall and cannot be accessed directly from the Internet.
[SNIP] There you go! The piece of information that makes it all click straight into place! Ok: Option 1) Try links in a local shell, and see if it can cope with the web pages, which, presumably, are management screens of some type. It may well solve the problem. Option 2) an OpenVPN tunnel from the boat (acting as a road warrior) to your intermediate host, using "OpenVPN user classes/policies" to control the access thereafter. See http://openvpn.net/index.php/open-source/documentation/howto.html#policy. Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com ---------------------------------------------------------------------
On Thu, Oct 04, 2012 at 08:38:10PM +0100, Keith Edmunds wrote:
On Thu, 4 Oct 2012 10:44:57 +0100, cl@isbd.net said:
I don't want it to provide any sort of access from outside, I just want to be able to reverse tunnel down the connection to access port 80 on the system on the boat.
In my opinion, you are making life unnecessarily complicated for yourself. The easy way to do this is to set up a VPN (OpenVPN is reasonably straightforward) from the boat to wherever you want, using multiple VPN connections if necessary. Then you can firewall incoming connections over the VPN to allow access from only those places you specify.
You may be right, I've just taken a look at OpenVPN and it looks do-able. However it's not immediately clear if it can actually do what I need. I would install OpenVPN server on my desktop here at home, lots of space, adequate CPU etc. and its accessible from the Internet via a firewall on which I can open up the necessary ports - so far so good. If I then run an OpenVPN client on the system on the boat will I be able to do what I want:- 1 - Run the OpenVPN client on the boat without user intervention? It's a minimal Ubuntu server installation, no GUI, little space, etc. 2 - Having done 1 can I then access the *client* from the server? 3 - security of the client system is unimportant really, if someone hacks into it and takes it completely apart I don't really care, however security of my home system *is* more important. So, I fear that 3 rather hits this on the head as if someone gets into the system on the boat (even simply breaks into the boat, not difficult) they would have access to my home system via the VPN wouldn't they? -- Chris Green
On 05/10/2012 11:24, Chris Green wrote:
On Thu, Oct 04, 2012 at 08:38:10PM +0100, Keith Edmunds wrote:
On Thu, 4 Oct 2012 10:44:57 +0100, cl@isbd.net said:
I don't want it to provide any sort of access from outside, I just want to be able to reverse tunnel down the connection to access port 80 on the system on the boat.
[SNIP] I'm still confused; not so much as to what you're trying to do as to why. Why are you trying to initiate all this from the boat, and especially via intermediaries? Why don't you secure the boat end, and connect directly to it? Alternatively, using shorewall and OpenVPN, why not make a permanent tunnel between the boay and your intermediate host, secured on said host with regard to onward access, only opening up access to your home system as and when required. For me, I'd secure the boat end, and go directly to it, but there must be a reason you haven't done that, because it's so obviously the simplest solution. Re: my previous post: links, btw, is a "A fast and lightweight [CLI] web browser running in both graphics and text mode" which is far, far more capable than lynx (http://links.twibright.com/) Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com ---------------------------------------------------------------------
On Fri, Oct 05, 2012 at 11:43:50AM +0100, Laurie Brown wrote:
On 05/10/2012 11:24, Chris Green wrote:
On Thu, Oct 04, 2012 at 08:38:10PM +0100, Keith Edmunds wrote:
On Thu, 4 Oct 2012 10:44:57 +0100, cl@isbd.net said:
I don't want it to provide any sort of access from outside, I just want to be able to reverse tunnel down the connection to access port 80 on the system on the boat.
[SNIP]
I'm still confused; not so much as to what you're trying to do as to why.
Why are you trying to initiate all this from the boat, and especially via intermediaries? Why don't you secure the boat end, and connect directly to it?
Because it's totally inaccessible from the internet, it's behind a NAT firewall in the WiFi server (which isn't mine and to which I have no access).
Alternatively, using shorewall and OpenVPN, why not make a permanent tunnel between the boay and your intermediate host, secured on said host with regard to onward access, only opening up access to your home system as and when required.
Where do I install OpenVPN? The boat system certainly hasn't the space or processor power to do it and anyway isn't accessible from the internet. I doubt if I can install OpenVPN on my hosting service though it *might* be possible, I'll investigate that route.
For me, I'd secure the boat end, and go directly to it, but there must be a reason you haven't done that, because it's so obviously the simplest solution.
Re: my previous post: links, btw, is a "A fast and lightweight [CLI] web browser running in both graphics and text mode" which is far, far more capable than lynx (http://links.twibright.com/)
Yes, I've been using w3m actually as it's more capable of dealing with the quirks of router web GUIs, but even then one nearly always needs a GUI browser to configure a router. -- Chris Green
On Fri, 5 Oct 2012 11:24:29 +0100, cl@isbd.net said:
If I then run an OpenVPN client on the system on the boat will I be able to do what I want:-
1 - Run the OpenVPN client on the boat without user intervention? It's a minimal Ubuntu server installation, no GUI, little space, etc.
Yes.
2 - Having done 1 can I then access the *client* from the server?
Yes.
3 - security of the client system is unimportant really, if someone hacks into it and takes it completely apart I don't really care, however security of my home system *is* more important.
Not a problem (at least, not one that can't be solved). Make your home system an OpenVPN server. The simple option is to create a certificate for OpenVPN and set up the boat to connect to home. The security at home is that no one without the certificate can connect. Set it up; say if you have problems. -- We're looking for smart Linux people: http://www.tiger-computing.co.uk/jobs
On Fri, Oct 05, 2012 at 08:58:12PM +0100, Keith Edmunds wrote:
On Fri, 5 Oct 2012 11:24:29 +0100, cl@isbd.net said:
If I then run an OpenVPN client on the system on the boat will I be able to do what I want:-
1 - Run the OpenVPN client on the boat without user intervention? It's a minimal Ubuntu server installation, no GUI, little space, etc.
Yes.
2 - Having done 1 can I then access the *client* from the server?
Yes.
3 - security of the client system is unimportant really, if someone hacks into it and takes it completely apart I don't really care, however security of my home system *is* more important.
Not a problem (at least, not one that can't be solved).
Make your home system an OpenVPN server. The simple option is to create a certificate for OpenVPN and set up the boat to connect to home. The security at home is that no one without the certificate can connect.
Yes, but the boat system isn't secure. So, if someone gains access (physical or virtual) they will have the certificate to connect to my home system. That's exactly why I don't allow direct access using ssh from the boat to my home system. -- Chris Green
On Sat, 6 Oct 2012 09:49:38 +0100, cl@isbd.net said:
Yes, but the boat system isn't secure. So, if someone gains access (physical or virtual) they will have the certificate to connect to my home system. That's exactly why I don't allow direct access using ssh from the boat to my home system.
So don't permit it via the VPN either. Here's some thoughts, and a question for you. The thoughts: You ask for some advice, receive a number of responses, and you decide to do something different (that you can't get to work). Then you find a really complex solution, which is less secure than some of the suggestions you received. I feel that those who responded have wasted their time and expertise trying to help you. The question: why would anyone on this list try to help you next time? -- We're looking for smart Linux people: http://www.tiger-computing.co.uk/jobs
Well I have a solution. I wasn't expecting this to work (two ssh tunnels sort of 'back to back') but it does:- On the boat system I do:- ssh -R 45678:localhost:80 myaccount@system.inthe.middle and on my home system:- ssh -L 45678:shell.gridhost.co.uk:45678 myaccount@system.inthe.middle then I can point my browser at localhost:45678 and it sees the apache server on the boat. It's as secure as I need. The boat has a passphraseless public key to log in to myaccount@system.inthe.middle so can connect unattended, the ssh process is kept going by a little utility called autossh that monitors it and restarts if necessary.
From my home system to myaccount@system.inthe.middle there's public key authentication with a passphrase protecting the key so it's "transparent" as long as I'm logged in. I can just fire off the ssh -L from my .xprofile.
As I say I hadn't realised that the two ssh tunnels would hook together so easily and painlessly, it just worked the first time I tried it and all I have to do in addition is add a couple of options to make it 'quieter' and everything is sorted. Thanks for all the help and thoughts, I may well investigate the VPN approach in the longer term as it might well provide a lot of things that I need all in one go. -- Chris Green
On Sat, 6 Oct 2012 10:03:34 +0100 Chris Green <cl@isbd.net> allegedly wrote:
Well I have a solution.
I really, really, /really/ do not understand why you must make things so complicated. What on earth is wrong with ssh (or VPN) inwards to the boat via port forwarding on the router? You can nail down the access to specific IP addresses. Confused of Tharston --------------------------------------------------------------------- blog: baldric.net fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 Note that I have recently upgraded my GPG key see: http://baldric.net/2012/07/20/gpg-key-upgrade/ ---------------------------------------------------------------------
On Sat, Oct 06, 2012 at 11:57:15AM +0100, mick wrote:
On Sat, 6 Oct 2012 10:03:34 +0100 Chris Green <cl@isbd.net> allegedly wrote:
Well I have a solution.
I really, really, /really/ do not understand why you must make things so complicated.
What on earth is wrong with ssh (or VPN) inwards to the boat via port forwarding on the router? You can nail down the access to specific IP addresses.
It can't be done because the boat is behind a NAT firewall, i.e. there are no interfaces visible from the internet. I have no control over the NAT, it's in the marina's WiFi. -- Chris Green
On Sat, 6 Oct 2012 12:52:39 +0100 Chris Green <cl@isbd.net> allegedly wrote:
It can't be done because the boat is behind a NAT firewall, i.e. there are no interfaces visible from the internet. I have no control over the NAT, it's in the marina's WiFi.
Then get control. Have you asked the provider to port forward to your router? If not try that. He may help. If you have tried and he has refused (or does refuse) change your provider. Buy yourself a 3G router and get a sim card from a provider which gives the best signal in your boat's area. Mick --------------------------------------------------------------------- blog: baldric.net fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 Note that I have recently upgraded my GPG key see: http://baldric.net/2012/07/20/gpg-key-upgrade/ ---------------------------------------------------------------------
On Sun, Oct 07, 2012 at 05:12:07PM +0100, mick wrote:
On Sat, 6 Oct 2012 12:52:39 +0100 Chris Green <cl@isbd.net> allegedly wrote:
It can't be done because the boat is behind a NAT firewall, i.e. there are no interfaces visible from the internet. I have no control over the NAT, it's in the marina's WiFi.
Then get control. Have you asked the provider to port forward to your router? If not try that. He may help. If you have tried and he has refused (or does refuse) change your provider. Buy yourself a 3G router and get a sim card from a provider which gives the best signal in your boat's area.
How can I change my provider? This is the WiFi provided free at the marina (well, tiny moorings with 12 boats) where we moor our boat. I don't even know what company it's from let alone have any sort of support access to them. We *have* a 3G router and a sim which we use when we're away from the moorings but it costs money to use that, the WiFi is 'free' (as in included in what we pay for the moorings). -- Chris Green
On Sun, 7 Oct 2012 17:46:08 +0100 Chris Green <cl@isbd.net> allegedly wrote:
How can I change my provider? This is the WiFi provided free at the marina (well, tiny moorings with 12 boats) where we moor our boat. I don't even know what company it's from let alone have any sort of support access to them.
But you have a contract with the Marina (I assume). They will know who provides the WiFi. Ask them. Asking costs nothing and at worst they can only say no.
We *have* a 3G router and a sim which we use when we're away from the moorings but it costs money to use that, the WiFi is 'free' (as in included in what we pay for the moorings).
Well that depends on how much you really want to do what you say. Mick --------------------------------------------------------------------- blog: baldric.net fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 Note that I have recently upgraded my GPG key see: http://baldric.net/2012/07/20/gpg-key-upgrade/ ---------------------------------------------------------------------
I'm a bit nervous about jumping in here but I don't see that what Chris wants to achieve is particularly unreasonable: remote access to the webserver on a Linux box that is "somewhere with an Internet connection", making as few assumptions as possible about that Internet connection, and doing it securely. I frequently need something similar myself[1], although with different criteria. As an example, I have one system on a site which is connected via a site network which connects to the Internet via satellite. Ie (Internet) -> (Satellite Router) -> (Site Router) -> (My Draytek router) -> My kit. Setting up port forwarding through there is not "fun", if indeed it is even possible, and it would be a solution that only worked there and not "in general". Generally 3G connections in my experience are not routable - usually I get a 10.x.x.x "external" IP address from the 3G provider which I have zero chance of port forwarding to. OpenVPN seems to be the best FOSS solution for the general case (getting "remote box with Internet connection" to connect to a known VPN server). Limiting that so that Chris can go through it to the web server on the remote box, whilst preventing anyone with physical access to that remote box from getting through to anything else on the VPN, may or may not be easy but it's beyond me. That said so is getting OpenVPN working in anything beyond simple test cases (I'm sure that's me not OpenVPN). [1] The best solution I've found is free beer only: https://secure.logmein.com/labs/#HamachiforLinux - but I don't think it would do what Chris needs security-wise otherwise I'd have mentioned it before. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On Mon, 08 Oct 2012 12:08:22 +0100 Mark Rogers <mark@quarella.co.uk> allegedly wrote:
OpenVPN seems to be the best FOSS solution for the general case (getting "remote box with Internet connection" to connect to a known VPN server). Limiting that so that Chris can go through it to the web server on the remote box, whilst preventing anyone with physical access to that remote box from getting through to anything else on the VPN, may or may not be easy but it's beyond me. That said so is getting OpenVPN working in anything beyond simple test cases (I'm sure that's me not OpenVPN).
Mark I had a think about this and then set up a test system to enable someone "on the internet" to connect to another system "on the internet" behind two (or more) NAT routers. I used a VPS as an intermediary so that the owner of the system behind the NAT addresses could set up a tunnel to the VPS. That would allow anyone else who could connect to the VPS to connect back down the tunnel. I've documented the setup at http://baldric.net/2012/10/27/using-openvpn-to-bypass-nat-firewalls/ Let me know if that helps (or not). If anything is unclear, or you can't get it to work, let me know and I'll modify the instructions accordingly. I'm hoping the instructions will help others so if I have made any mistakes (or made too many assumptions) it would be good to know. Cheers Mick --------------------------------------------------------------------- blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 ---------------------------------------------------------------------
On Sat, Oct 27, 2012 at 06:02:47PM +0100, mick wrote:
On Mon, 08 Oct 2012 12:08:22 +0100 Mark Rogers <mark@quarella.co.uk> allegedly wrote:
OpenVPN seems to be the best FOSS solution for the general case (getting "remote box with Internet connection" to connect to a known VPN server). Limiting that so that Chris can go through it to the web server on the remote box, whilst preventing anyone with physical access to that remote box from getting through to anything else on the VPN, may or may not be easy but it's beyond me. That said so is getting OpenVPN working in anything beyond simple test cases (I'm sure that's me not OpenVPN).
Mark
I had a think about this and then set up a test system to enable someone "on the internet" to connect to another system "on the internet" behind two (or more) NAT routers.
I used a VPS as an intermediary so that the owner of the system behind the NAT addresses could set up a tunnel to the VPS. That would allow anyone else who could connect to the VPS to connect back down the tunnel.
I've documented the setup at http://baldric.net/2012/10/27/using-openvpn-to-bypass-nat-firewalls/
Let me know if that helps (or not). If anything is unclear, or you can't get it to work, let me know and I'll modify the instructions accordingly. I'm hoping the instructions will help others so if I have made any mistakes (or made too many assumptions) it would be good to know.
That's fantastic! :-) It's a *lot* of work compared with my direct use of ssh though (now I have it working). I will quite likely come back to it though as it's a more general sort of solution. Thank you. -- Chris Green
On 04/10/12 09:50, Laurie Brown wrote:
What you could try, if as I suspect, you wish to limit access to the remote machine, is to use port-knocking and iptables to open the tunnel up, AND use certificate pairs. http://en.gentoo-wiki.com/wiki/Port_Knocking http://www.hostsvault.com/blog/howto-protect-services-like-ssh-against-brute... http://www.soloport.com/iptables.html I'm a big fan of Shorewall, so: http://www.shorewall.net/3.0/PortKnocking.html HtH. Laurie.
Hi, I'm not entirely convinced by port knocking. http://bsdly.blogspot.co.uk/2012/04/why-not-use-port-knocking.html If you're behind a firewall and only the port-knocking ports are open, and they're in numeric order, then someone just doing a simple consecutive port scan might unlock your SSH port. I'm not saying don't do it, but just that I'm not convinced! If you want to beef up security though, some of the other things in that article are useful. Disable root logins - obviously! Move your SSH port to a different address - when I did this the number of attempted logins on my server went from multiple attempts a day to perhaps one every 3-4 months! Install Fail2Ban or DenyHosts. Denyhosts can download a list of IP addresses that have been scanning SSH ports and block them from accessing your system, and will also block your ssh port from being accessed from and ip address that does repeated failed log-in attempts. Limiting logins from specific IP addresses as you already do is a good idea. I'm not absolutely sure what you're trying to do - I don't quite understand why you're reverse tunneling for instance. Anyway, on the off-chance that this helps. You can/should set up a user-name on the remote machine with little or no privileges to do anything, however, allow this account to be SSH-ed into. Then you can configure Sudo for this account so that it specifically allows you to run the commands that you want it to, in conjunction with Sudo. Configure sudo with the visudo command, but google it first, or look at a manual. Hope this helps a bit! Steve
On Thu, Oct 04, 2012 at 02:44:27PM +0100, steve-ALUG@hst.me.uk wrote:
Limiting logins from specific IP addresses as you already do is a good idea.
I get *very* few ssh login attempts, just the odd one every few days. It's presumably just the occasional user who also has an account at the same hosting service as me (Tsohost, excellent).
I'm not absolutely sure what you're trying to do - I don't quite understand why you're reverse tunneling for instance. Anyway, on the off-chance that this helps.
You can/should set up a user-name on the remote machine with little or no privileges to do anything, however, allow this account to be SSH-ed into. Then you can configure Sudo for this account so that it specifically allows you to run the commands that you want it to, in conjunction with Sudo. Configure sudo with the visudo command, but google it first, or look at a manual.
'Remote' doesn't really make sense in this context! :-) There's a Ubuntu machine on our boat in France that runs unattended. It already runs an autossh process at startup that sets up an ssh tunnel to my login at Tsohost. This allows me to login to my Tsohost shell and, from there to login to the Ubuntu machine on the boat. The reason for using the Tsohost 'intermediate' shell account is simply that I don't want public-key/no passphrase logins on my home desktop machine. The Ubuntu machine on the boat runs apache and I want to be able to browse its web pages from home. So I want to 'export' port 80 from the machine on the boat in the same way as I export port 22 for ssh. However I'd like to be able to export it direct to my desktop machine, which entails having a public-key/no passphrase login so I want to make it so that login won't allow anything except the ssh reverse tunnel. -- Chris Green
On Thu, Oct 04, 2012 at 03:16:51PM +0100, Chris Green wrote:
The Ubuntu machine on the boat runs apache and I want to be able to browse its web pages from home. So I want to 'export' port 80 from the machine on the boat in the same way as I export port 22 for ssh. However I'd like to be able to export it direct to my desktop machine, which entails having a public-key/no passphrase login so I want to make it so that login won't allow anything except the ssh reverse tunnel.
You can write options into the authorized_keys on the server end and limit what the client can do from there, no idea if it will allow you to do what you want. man sshd and search for AUTHORIZED_KEYS Adam
participants (8)
-
Adam Bower -
Chris Green -
Jude Lucien -
Keith Edmunds -
Laurie Brown -
Mark Rogers -
mick -
steve-ALUG＠hst.me.uk