[Server-devel] [support-gang] Value of remote access to School Servers.

James Cameron quozl at laptop.org
Wed Jul 3 05:10:21 EDT 2013

On Wed, Jul 03, 2013 at 02:06:04PM +0530, Anish Mangal wrote:
> On Wed, Jul 3, 2013 at 1:54 PM, James Cameron <quozl at laptop.org> wrote:
>     On Wed, Jul 03, 2013 at 12:45:35PM +0530, Anish Mangal wrote:
>     > James wrote:
>     > > Would the person accessing their XSCE remotely then establish
>     > > another tunnel to your OpenVPN server, or would your server do
>     > > inbound connection forwarding?
>     >
>     > Hmm. I'm not so clear on that. I can give the example of a setup in
>     > Bhagmalpur (a pilot we recently did).
>     >
>     > 1. There is an openVPN server hosted by Sameer.
>     > 2. The XSCE when connected to the internet dials into this open vpn
>     >    server.
>     Thanks, I understand the first two steps, and they sound good.
>     > 3. I can login to the XSCE through the openVPN connection through
>     >    ssh and administer remotely.
>     How is this last step achieved?  There's much flexibility, so I'm
>     curious.  I imagine one of three methods:
>     a.  does the user first SSH into an account on the OpenVPN server and
>     then SSH again to the XSCE, or;
>     b.  does the user SSH to a particular port on the OpenVPN server that
>     is automatically forwarded to the XSCE, or;
>     c.  does the XSCE have a routable IP address, courtesy of the OpenVPN
>     server, to which SSH is directed?
> I'm not sure... let me explain (perhaps Sameer or Santi can chime in)...
> I have a set of openVPN keys on may laptop through which I connect to the
> openVPN server automatically (and a network called tun0 is created)
> I know the IP address of the XSCE in Bpur
> So, from my laptop, I just do ssh root@<ip address of XSCE on the openVPN
> network>
> Does it make things any clearer?

Yes, this would be a case "d", where both the client (your laptop) and
the server (the XSCE) have an unroutable address on a network that is
unreachable except through OpenVPN.

By unroutable I mean one that cannot be reached from the public

This is a good choice, because:

- it allows the server hosting the OpenVPN to avoid dealing with
  traffic unrelated to the task of remote access,

- it allows the administrator of the OpenVPN server to set up packet
  filtering rules to permit specific individuals to access specific

- it prevents access to either party from the public network.

Now that you have remote XSCE settled, have you considered remote XO
access for hardware diagnosis and maintenance?  Write up of that
feature is here:


A relay using socat could be run on the XSCE for this purpose, and so
a user of the OpenVPN service could reach an XO (or another XSCE) to
analyse or fix non-booting scenarios.

I know you already have the capability to deploy puppet for XO remote
administration ... if the Linux kernel is running.

James Cameron

More information about the Server-devel mailing list