Hello. I have a remote server inside a remote office covered by NAT
masquerade where port forwarding not possible, and a local server in my
local office not covered by NAT masquerade. In order to access the
remote office and hosts in that office, I do this:

On remote office server, in a screen session I run
$ ssh -R .... local_server

On my own office, I try to connect to mapped ports on local_server.

The problem of this solution is security. I do not want to grant shell
access of local_server to remote_server. What would you recommend me to
do in this case? I could try to limit access of the account used by
remote server ssh -R, but should I?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Nov 11, 2009 at 10:36:20AM +0800, Zhang Weiwu wrote:
> Hello. I have a remote server inside a remote office covered by NAT
> masquerade where port forwarding not possible, and a local server in my
> local office not covered by NAT masquerade. In order to access the
> remote office and hosts in that office, I do this:
>
> On remote office server, in a screen session I run
> $ ssh -R .... local_server
>
> On my own office, I try to connect to mapped ports on local_server.
>
> The problem of this solution is security. I do not want to grant shell
> access of local_server to remote_server. What would you recommend me to
> do in this case? I could try to limit access of the account used by
> remote server ssh -R, but should I?

have you thought about openvpn and iptables ?

>
>

--
"A tax cut is really one of the anecdotes to coming out of an economic illness."

- George W. Bush
09/18/2000
The Edge With Paula Zahn

Alex Samad wrote:
> On Wed, Nov 11, 2009 at 10:36:20AM +0800, Zhang Weiwu wrote:
>
>> The problem of this solution is security. I do not want to grant shell
>> access of local_server to remote_server. What would you recommend me to
>> do in this case? I could try to limit access of the account used by
>> remote server ssh -R, but should I?
>>
>
> have you thought about openvpn and iptables?
>
I am a clueless guy in regarding to both. Would be better if you are
more specific which feature of the two software are useful, then I can
be more specific when RTFM. Knowing it is possible with certain
technology makes better use of time as I have too much pressure at the
time to deal with all problems that try to make best use of learning
time.. Sorry...


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Nov 11, 2009 at 10:36, Zhang Weiwu <zhangweiwu@realss.com> wrote:
> Hello. I have a remote server inside a remote office covered by NAT
> masquerade where port forwarding not possible, and a local server in my
> local office not covered by NAT masquerade. In order to access the
> remote office and hosts in that office, I do this:
>
> On remote office server, in a screen session I run
> $ ssh -R .... *local_server
You may want to run ``$ ssh -N -R .... _local_server' instead.
Please refer to the manpage for further details.

>
> On my own office, I try to connect to mapped ports on local_server.
>
> The problem of this solution is security. I do not want to grant shell
> access of local_server to remote_server. What would you recommend me to
> do in this case? I could try to limit access of the account used by
> remote server ssh -R, but should I?
>

Regards,
Wang Long


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Nov 11, 2009 at 10:36:20AM +0800, Zhang Weiwu wrote:

> The problem of this solution is security. I do not want to grant shell
> access of local_server to remote_server. What would you recommend me
> to do in this case? I could try to limit access of the account used by
> remote server ssh -R, but should I?

You don't have to grant the remote server shell access if you don't want
to. You can use the port-forward feature of ssh to just create ports
without a shell with the -fN flag.

Also, the -R and -L flags look the same, but define which end the
traffic originates from. So, it's hard to say if you're using -R
correctly, or if you should be using -L instead.

This is untested, but should work to tunnel SMTP from localserver to
remoteserver when the connection is opened from the remoteserver side:

remoteserver$ ssh -fN -R25:localhost:25 localserver

to make it work securely, though, you need to do a few more things.

1. Add the "no-pty" option to your authorized_keys file so that no
shell is allowed for that key.

2. See whether you can limit the forwarded ports with "permitopen"
in authorized_keys. This may or may not work with -R; the man
page says it's for -L only.

3. Consider creating a non-root user for ports that don't require
binding to privileged ports. For example, you could tunnel git on
port 9418 as some other user rather than root.

If you want a real SSH-based VPN, and are willing to pay the encryption
overhead, you can investigate SSH + TUN forwardings. See these articles
as a starting point:

http://www.debian-administration.org/articles/539
https://help.ubuntu.com/community/SSH_VPN
http://www.gentoo-wiki.info/HOWTO_VPN_over_SSH_and_tun

Hope that helps.

--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Zhang Weiwu wrote at 2009-11-10 20:36 -0600:
> Hello. I have a remote server inside a remote office covered by NAT
> masquerade where port forwarding not possible, and a local server in my
> local office not covered by NAT masquerade. In order to access the
> remote office and hosts in that office, I do this:
>
> On remote office server, in a screen session I run
> $ ssh -R .... local_server
>
> On my own office, I try to connect to mapped ports on local_server.
>
> The problem of this solution is security. I do not want to grant shell
> access of local_server to remote_server. What would you recommend me to
> do in this case? I could try to limit access of the account used by
> remote server ssh -R, but should I?

You might want to check out apf-server and apf-client packages. I use these to
provide access between masqueraded systems using an intermediary system.
Server runs on the intermediary and client on the system to be connected to.
System connected _from_ connects to client through a port on the server.

Hi.

On 2009年11月12日 07:53, green wrote:
> Zhang Weiwu wrote at 2009-11-10 20:36 -0600:
>
>> Hello. I have a remote server inside a remote office covered by NAT
>> masquerade where port forwarding not possible, and a local server in my
>> local office not covered by NAT masquerade. In order to access the
>> remote office and hosts in that office, I do this:
>>
>> On remote office server, in a screen session I run
>> $ ssh -R .... local_server
>>
>> On my own office, I try to connect to mapped ports on local_server.
>>
>> The problem of this solution is security. I do not want to grant shell
>> access of local_server to remote_server. What would you recommend me to
>> do in this case? I could try to limit access of the account used by
>> remote server ssh -R, but should I?
>>
> You might want to check out apf-server and apf-client packages. I use these to
> provide access between masqueraded systems using an intermediary system.
> Server runs on the intermediary and client on the system to be connected to.
> System connected _from_ connects to client through a port on the server.
>
Thank you! Now that I tried it, te apf-client package proved very useful
in my case. I followed your advice almost a year later because I was too
busy with daily business and kept your email as "marked for personal
todo" for a year or so.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C8DD155.3040905@realss.com">http://lists.debian.org/4C8DD155.3040905@realss.com

Zhang Weiwu wrote at 2010-09-13 02:23 -0500:
> Thank you! Now that I tried it, te apf-client package proved very useful
> in my case. I followed your advice almost a year later because I was too
> busy with daily business and kept your email as "marked for personal
> todo" for a year or so.

Excellent! Now we can await global ipv6 as a better solution.