Ssh – Port forwarding for Rsync

port-forwardingrsyncssh

Every port on my server is blocked except port 222 which is were ssh connects too. This server is pretty much a backup server, and I have my clients rsync to it.

I do this by using ssh's port forwarding (-P 222 -L 873:myserver.com:873), however, I want to do this with just using the rsync command. Is that possible?

This is what I've been trying:

sudo rsync -avv --progress --inplace --rsh='ssh -p 222 -L 873:myserver.com:873' . rsync://bt-backup@localhost/backup-bt-backup

but it doesn't work because I try to log into localhost, instead of myserver.com.

doing:

sudo rsync -avv --progress --inplace --rsh='ssh -p 222 -L 873:myserver.com:873' . rsync://bt-backup@myserver.com/backup-bt-backup

lets me login through ssh, but rsync tries the remote host instead of the localhost where the port has been forwarded too

Best Answer

If the server is running SSHd then you can just use rsync over SSH directly.

For instance I run things like
rsync -a --inplace some/dir/ user@remote.server.tld:/destination/dir/
all the time. There is no need to run rsync as a daemon or have port forwarding enabled as rsync will start a copy of itself using the SSH link and handle all synchronisation between itself and that instance over the SSH link too (and the remote copy closes as the connection is dropped so you don't end up with a bunch of zombie processes hanging around).

To talk over a port other than the standard one you just need to give rsync a little extra info about how it should manage the connection, like so:
rsync -a --inplace -e 'ssh -p 222' some/dir/ user@remote.server.tld:/destination/dir/

This is actually more secure (all the rsync communication is protected by SSHs secure transport, whereas with port forwarding everything is sent plain) and more convenient (no rsyncd needed, and you can use SSHs key based auth)

Related Solutions

Ssh-agent forwarding and sudo to another user

As you mentioned, the environment variables are removed by sudo, for security reasons.

But fortunately sudo is quite configurable: you can tell it precisely which environment variables you want to keep thanks to the env_keep configuration option in /etc/sudoers.

For agent forwarding, you need to keep the SSH_AUTH_SOCK environment variable. To do so, simply edit your /etc/sudoers configuration file (always using visudo) and set the env_keep option to the appropriate users. If you want this option to be set for all users, use the Defaults line like this:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers for more details.

You should now be able to do something like this (provided user1's public key is present in ~/.ssh/authorized_keys in user1@serverA and user2@serverB, and serverA's /etc/sudoers file is setup as indicated above):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

Ubuntu server refusing connections via port forwarding

Does restarting the ubuntu server or the verizon firewall make it start working again temporarily?

To check the status of your firewall rules, use

sudo /sbin/iptables -nvL |less

what do you see there? Save that output right after restart and then compare to when it stops working - is some other process mucking with your firewall rules (via crontab maybe)? Seems odd, but that could explain the behavior you are seeing.

Best Answer

Related Solutions

Ssh-agent forwarding and sudo to another user

Ubuntu server refusing connections via port forwarding

Related Topic