[Leaplist] duplicity recommendation - with a twist

[Mark W. Alexander]

On Sun, Jan 13, 2008 at 01:40:19PM -0500, Chris wrote:
> Thanks for the writeup - coincidently, I'm trying to solve a similar
> problem this weekend, but I have one additional complexity - a
> firewall.
> 
> Looks like this:
> LocalLinux<--->RemoteBSDFirewall<--->ServerBehindFirewall
> 
> I need to back up ServerBehindFirewall to LocalLinux, but I
> haven't figured out how to slide ssh through RemoteBSDFirwall.
> 
> I have root access on all three machines, so it should be easy,
> sort of, but I haven't figured out how to put all the pieces together.
> 
> One less-than optimal solution might be to configure port forwarding
> on RemoteBSDFirewall to slide all ssh packets directly between
> ServerBehindFirewall. That seems a bit like using a sledgehammer
> to drive a thumbtack, but...
> 
> This can't be a unique scenario, but I still haven't stumbled across
> the right documentation.
> 
> Any clues, cookie crumbs appreciated.

You can tunnel ssh over ssh. Set up a tunnel with:

  ssh -f -N -L 2222:server.behind.firewall:22 remote.bsd.firewall

The -f forks the tunnel into the background. The -N says don't execute anything
on remote.bsd.firewall. The -L 2222:server.behind.firewall:22 says bind
localhost:2222 to server.behind.firewall:22. So once you've done that you can
use the ssh -p option with ssh, or anything that uses ssh (like rsync!) to run
through the firewall. IOW,

  ssh -p 2222 localhost

will jump you to a prompt on server.behind.firewall

Note that if you `ps -ef|grep ssh` you'll see the ssh tunnel running in the
background.  Forever! Or at least until you kill it. As long as it's there, you
don't have to make another. Feel free to open more terminals and "ssh -p 2222
localhost" again and you'll get another session. And another. And another. And
if you close them all but leave the tunnel running you can do it again
tomorrow, next week or next year.

To use with rsync, you'd use rsync's --rsh="ssh -p 2222" and use localhost as
if it where server.behind.firewall.

A small annoyance if you do this a lot is you get host key collisions in
known_hosts because you're using localhost for oodles of hosts that don't have
the same host key. You can get around that with ssh's 

  -o UserKnownHostsFile=/tmp/different_each_run

You'll have to say "yes" every time you connect to a host using an empty
known_hosts. Alternatively you use unique known_hosts files that match your
localhost "spoofed" destinations.

Cheap plug: You might try pyssh.sourceforge.net which I touched a few years ago
and became maintainer of. PySSH has an SSHTunnel class that will do this mostly
automagically, including answering "yes" if it needs to and attaching to an
ssh-agent if it can find it. (Actually, I don't remember if I released
SSHTunnel so if it isn't there ping me and I'll update it.)

Quick dodge: http://pypi.python.org/pypi/paramiko is "real" python SSH module.
I haven't had a chance to look at it, so I don't know it's capabilities, but it
is supported.  PySSH is a hack and I will not be enhancing it unless it turns
out that paramiko really sucks when I finally get time to try it. It just
happens that PySSH is a hack I know and made do what I want it to do.

/me loves his ssh
mwa
-- 
Mark W. Alexander
slash at dotnetslash.net

The contents of this message authored by Mark W. Alexander are released under
the Creative Commons Attribution-NonCommercial license.  Copyright of quoted
materials, if any, are retained by the original author(s).

http://creativecommons.org/licenses/by-nc/2.0/