rsync over active ssh connection The Next CEO of Stack Overflowrsync over ssh - encryption on...
Why is the US ranked as #45 in Press Freedom ratings, despite its extremely permissive free speech laws?
Rotate a column
How many extra stops do monopods offer for tele photographs?
Why is Germany producing more waste than US?
The exact meaning of 'Mom made me a sandwich'
Does increasing your ability score affect your main stat?
Do I need to write [sic] when a number is less than 10 but isn't written out?
Newlines in BSD sed vs gsed
Break Away Valves for Launch
Why, when going from special to general relativity, do we just replace partial derivatives with covariant derivatives?
Why the difference in type-inference over the as-pattern in two similar function definitions?
Solving system of ODEs with extra parameter
Bartok - Syncopation (1): Meaning of notes in between Grand Staff
Why does standard notation not preserve intervals (visually)
Why isn't the Mueller report being released completely and unredacted?
Why do airplanes bank sharply to the right after air-to-air refueling?
Prepend last line of stdin to entire stdin
Flying from Cape Town to England and return to another province
Writing differences on a blackboard
WOW air has ceased operation, can I get my tickets refunded?
Why is my new battery behaving weirdly?
Math-accent symbol over parentheses enclosing accented symbol (amsmath)
Can MTA send mail via a relay without being told so?
Unclear about dynamic binding
rsync over active ssh connection
The Next CEO of Stack Overflowrsync over ssh - encryption on serverrsync via multiple ssh connections with a keyIntermittent rsync over ssh errors via cron w/ Ubuntu 10.04: unexplained & protocol data streamsetting up a password for cron rsync over sshNeed passwordless rsync — remote server doesn't allow ssh keyfilessshd_config ForceCommand /usr/bin/rsync error “connection unexpectedly closed”ssh connection operation timed out using rsyncrsync from remote ssh server with forwarded keysssh connects okay from command line but from cron using publickeyHost Key verification failed SSH Rsync
Trying to script as clean as possible, I wonder if there is some solution for the following situation:
One Linux server running sshd and one android device, with dropbear ssh client and rsync installed (no server).
I'm writing a script to be run remotely with a cron that backups the android memory to the linux server. The cron calls something like:
ssh remoteuser@linuxserver -i path_to_rsa_key runthisscript.sh
runthisscript.sh performs a few things with the existent data, and, what I want to do, in the middle of the script, is to rsync from the android device back to the server, taking advantage of the ssh connection that is already opened (as there is no sshd running on the android).
I've developed other solutions, like breaking my server script in several parts and calling them one after another, with the rsync (android to server direction) in the middle, but I was looking for a more elegantly implemented solution (single script, most of the work done in the server side).
Ideas?
ssh rsync
bumped to the homepage by Community♦ 13 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
Trying to script as clean as possible, I wonder if there is some solution for the following situation:
One Linux server running sshd and one android device, with dropbear ssh client and rsync installed (no server).
I'm writing a script to be run remotely with a cron that backups the android memory to the linux server. The cron calls something like:
ssh remoteuser@linuxserver -i path_to_rsa_key runthisscript.sh
runthisscript.sh performs a few things with the existent data, and, what I want to do, in the middle of the script, is to rsync from the android device back to the server, taking advantage of the ssh connection that is already opened (as there is no sshd running on the android).
I've developed other solutions, like breaking my server script in several parts and calling them one after another, with the rsync (android to server direction) in the middle, but I was looking for a more elegantly implemented solution (single script, most of the work done in the server side).
Ideas?
ssh rsync
bumped to the homepage by Community♦ 13 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
oreilly.com/pub/h/38
– dmourati
Jan 4 '14 at 22:00
add a comment |
Trying to script as clean as possible, I wonder if there is some solution for the following situation:
One Linux server running sshd and one android device, with dropbear ssh client and rsync installed (no server).
I'm writing a script to be run remotely with a cron that backups the android memory to the linux server. The cron calls something like:
ssh remoteuser@linuxserver -i path_to_rsa_key runthisscript.sh
runthisscript.sh performs a few things with the existent data, and, what I want to do, in the middle of the script, is to rsync from the android device back to the server, taking advantage of the ssh connection that is already opened (as there is no sshd running on the android).
I've developed other solutions, like breaking my server script in several parts and calling them one after another, with the rsync (android to server direction) in the middle, but I was looking for a more elegantly implemented solution (single script, most of the work done in the server side).
Ideas?
ssh rsync
Trying to script as clean as possible, I wonder if there is some solution for the following situation:
One Linux server running sshd and one android device, with dropbear ssh client and rsync installed (no server).
I'm writing a script to be run remotely with a cron that backups the android memory to the linux server. The cron calls something like:
ssh remoteuser@linuxserver -i path_to_rsa_key runthisscript.sh
runthisscript.sh performs a few things with the existent data, and, what I want to do, in the middle of the script, is to rsync from the android device back to the server, taking advantage of the ssh connection that is already opened (as there is no sshd running on the android).
I've developed other solutions, like breaking my server script in several parts and calling them one after another, with the rsync (android to server direction) in the middle, but I was looking for a more elegantly implemented solution (single script, most of the work done in the server side).
Ideas?
ssh rsync
ssh rsync
asked Jan 4 '14 at 21:51
Abilio MarquesAbilio Marques
161
161
bumped to the homepage by Community♦ 13 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 13 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
oreilly.com/pub/h/38
– dmourati
Jan 4 '14 at 22:00
add a comment |
oreilly.com/pub/h/38
– dmourati
Jan 4 '14 at 22:00
oreilly.com/pub/h/38
– dmourati
Jan 4 '14 at 22:00
oreilly.com/pub/h/38
– dmourati
Jan 4 '14 at 22:00
add a comment |
2 Answers
2
active
oldest
votes
I assume you want to be able to connect from anywhere, so you can't garantee what public IP address the tablet will be on (or even if that will allow connections to the tablet from the server, as it is unlikely to be a public address), otherwise you should install a SSH deamon and ash rsync to connect that way. Otherwise, a "reverse tunnel" may be what you are looking for.
If your SSH client on the Android device supports reverse port forwarding then look into using that to build a tunnel. For instance with openssh you can specify -R 2222:127.0.0.1:22 on the command line which would mean things on the server can connect to a SSHd server on the tablet (listening on port 22 on 127.0.0.1 as far as the tablet is concerned) by connecting to port 2222 on 127.0.0.1 (it is important to realise that from the code on the server's PoV 127.0.0.1 is the server, the 127.0.0.1 in the command line is relative the the SSH client). So if that works you can in your server script run something like rsync user@127.0.0.1:/path/to/stuff/on/tablet /path/to/destination/on/server -e 'ssh -p 2222' -a --compress. The -e option is used here to specify the non-standard port for SSH to connect to.
Some more detailed notes on the above (sorry, this is bit of a "mind dump" and may not be well organsied, though hopefully it'll help you experiemnt and/or lookup useful examples elsewhere):
- This is called a reverse or remote tunnel because it is more usual to setup redirects fomr the client to the server (not the server to the client as you need here). A local tunnel (client-side to something server-side) is setup using the
-Loption instead of-R(at least with OpenSSH, check your server's documentation for confirmation). - You can give many
-Rand/or-Loptions on the same command line with OpenSSH, so you can setup more than one tunnel in either/any direction using a single SSH connection. - You may need
GatewayPorts yesor similar specified in the server'ssshd_configfor reverse tunnels to work at all. Check your SSHd implementation's documentation for details. - It doesn't matter where the tablet calls from: the tunnel created by the port forward will always point (via the SSH connection) back to its SSH client. You could even point it at some other local resource with a forward like
-R 8888:192.168.42.42:80which will mean connections to 127.0.0.1:8888 on the server will go through the SSH tunnel and hit port 80 on what-ever machine answers to 192.168.42.42 on the network the tablet is currently on (this could even be another remote machine in a completely different location). - You will need the rsync client on the tablet to the server can run it over SSH via the tunnel.
- The above example uses a non-standard port as SSHd is likely to be listening on port 22 on all interfaces on the server. If you are connecting to the server as root then using a port number below 1024 (i.e. 222 instead of 2222) is safer, though you should avoid being connect to remote resources as root where possible. Listending on a port below 1024 is blocked for non-privelaged users by default on Uinx-a-like systems.
- If you don't want to run a SSH daemon on the tablet, you could instead run an instance of rsync in daemon mode instead. The port forward would then be something like
537:127.0.0.1:537or (if you are running rsync in server mode on the server already so port 537 is taken, something like5537:127.0.0.1:537and add-p 5537to the rsync command to tell it the server is not in the standard place). - If your server's SSHd does not listen on port 22 on all the server's interfaces/addresses, then you could use 22 instead of a non-standard port by specifying that the tunnel should attact to a specific interface by adding that address to the start of the
-Rpart, like so:-R 192.168.1.1:22:127.0.0.1:22. The bind address is relative to the server so does not need to be something that is publically routable (in fact an address on a dummy interface even the rest of the local LAN can't see would work). You definitely needGatewayPortson for this to work with OpenSSH. If you don't needGatewayPortson (i.e. if using 127.0.0.1 server-side and a non-standard port and that works with your server's SSHd implementation withoutGatewayPorts yesor equivelant) then leave it off: it is safer this way. - I've assumed IPv4 in all of the above. If your client and server both support it and your networks at each end are appropriately configued, IPv6 addressing will work just as well.
Tunnels through SSH ocnfigured this way can be very powerful once you have played with them and work out what it possible and how to do it, assuming your client and server SSH/SSHd implementations support it all.
add a comment |
You may have a look at --rsh/-e argument of rsync.
You can replace the rsh with cat or something similar. But you have to add a script at android side which sends the output of your server script to a shell.
Android side:
socat 'EXEC:/bin/bash' 'TCP-LISTEN:20000' &
ssh remoteuser@linuxserver -i path_to_rsa_key -R 20000:127.0.0.1:20000 runthisscript.sh
helper.sh:
#!/bin/sh
host=$2
port=$1
shift 2
{
echo exec "$@"
socat 'STDIN' 'STDOUT'
} | socat '-' "TCP:$host:$port"
runthisscript.sh:
rsync -e './helper.sh 20000' --blocking-io <SRC> <DST>
Can you specify a bit more?
– Abilio Marques
Jan 4 '14 at 22:24
I have edited the answer. But its not complete. If you want better security, you should bindbashdirectly to stdio ofssh. It's not a good idea to bindbashto an ip port, even a local port. And consider add more arguments tosocatto do non-blocking io so that it could be faster.
– Sherwood Wang
Jan 5 '14 at 5:52
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f565083%2frsync-over-active-ssh-connection%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I assume you want to be able to connect from anywhere, so you can't garantee what public IP address the tablet will be on (or even if that will allow connections to the tablet from the server, as it is unlikely to be a public address), otherwise you should install a SSH deamon and ash rsync to connect that way. Otherwise, a "reverse tunnel" may be what you are looking for.
If your SSH client on the Android device supports reverse port forwarding then look into using that to build a tunnel. For instance with openssh you can specify -R 2222:127.0.0.1:22 on the command line which would mean things on the server can connect to a SSHd server on the tablet (listening on port 22 on 127.0.0.1 as far as the tablet is concerned) by connecting to port 2222 on 127.0.0.1 (it is important to realise that from the code on the server's PoV 127.0.0.1 is the server, the 127.0.0.1 in the command line is relative the the SSH client). So if that works you can in your server script run something like rsync user@127.0.0.1:/path/to/stuff/on/tablet /path/to/destination/on/server -e 'ssh -p 2222' -a --compress. The -e option is used here to specify the non-standard port for SSH to connect to.
Some more detailed notes on the above (sorry, this is bit of a "mind dump" and may not be well organsied, though hopefully it'll help you experiemnt and/or lookup useful examples elsewhere):
- This is called a reverse or remote tunnel because it is more usual to setup redirects fomr the client to the server (not the server to the client as you need here). A local tunnel (client-side to something server-side) is setup using the
-Loption instead of-R(at least with OpenSSH, check your server's documentation for confirmation). - You can give many
-Rand/or-Loptions on the same command line with OpenSSH, so you can setup more than one tunnel in either/any direction using a single SSH connection. - You may need
GatewayPorts yesor similar specified in the server'ssshd_configfor reverse tunnels to work at all. Check your SSHd implementation's documentation for details. - It doesn't matter where the tablet calls from: the tunnel created by the port forward will always point (via the SSH connection) back to its SSH client. You could even point it at some other local resource with a forward like
-R 8888:192.168.42.42:80which will mean connections to 127.0.0.1:8888 on the server will go through the SSH tunnel and hit port 80 on what-ever machine answers to 192.168.42.42 on the network the tablet is currently on (this could even be another remote machine in a completely different location). - You will need the rsync client on the tablet to the server can run it over SSH via the tunnel.
- The above example uses a non-standard port as SSHd is likely to be listening on port 22 on all interfaces on the server. If you are connecting to the server as root then using a port number below 1024 (i.e. 222 instead of 2222) is safer, though you should avoid being connect to remote resources as root where possible. Listending on a port below 1024 is blocked for non-privelaged users by default on Uinx-a-like systems.
- If you don't want to run a SSH daemon on the tablet, you could instead run an instance of rsync in daemon mode instead. The port forward would then be something like
537:127.0.0.1:537or (if you are running rsync in server mode on the server already so port 537 is taken, something like5537:127.0.0.1:537and add-p 5537to the rsync command to tell it the server is not in the standard place). - If your server's SSHd does not listen on port 22 on all the server's interfaces/addresses, then you could use 22 instead of a non-standard port by specifying that the tunnel should attact to a specific interface by adding that address to the start of the
-Rpart, like so:-R 192.168.1.1:22:127.0.0.1:22. The bind address is relative to the server so does not need to be something that is publically routable (in fact an address on a dummy interface even the rest of the local LAN can't see would work). You definitely needGatewayPortson for this to work with OpenSSH. If you don't needGatewayPortson (i.e. if using 127.0.0.1 server-side and a non-standard port and that works with your server's SSHd implementation withoutGatewayPorts yesor equivelant) then leave it off: it is safer this way. - I've assumed IPv4 in all of the above. If your client and server both support it and your networks at each end are appropriately configued, IPv6 addressing will work just as well.
Tunnels through SSH ocnfigured this way can be very powerful once you have played with them and work out what it possible and how to do it, assuming your client and server SSH/SSHd implementations support it all.
add a comment |
I assume you want to be able to connect from anywhere, so you can't garantee what public IP address the tablet will be on (or even if that will allow connections to the tablet from the server, as it is unlikely to be a public address), otherwise you should install a SSH deamon and ash rsync to connect that way. Otherwise, a "reverse tunnel" may be what you are looking for.
If your SSH client on the Android device supports reverse port forwarding then look into using that to build a tunnel. For instance with openssh you can specify -R 2222:127.0.0.1:22 on the command line which would mean things on the server can connect to a SSHd server on the tablet (listening on port 22 on 127.0.0.1 as far as the tablet is concerned) by connecting to port 2222 on 127.0.0.1 (it is important to realise that from the code on the server's PoV 127.0.0.1 is the server, the 127.0.0.1 in the command line is relative the the SSH client). So if that works you can in your server script run something like rsync user@127.0.0.1:/path/to/stuff/on/tablet /path/to/destination/on/server -e 'ssh -p 2222' -a --compress. The -e option is used here to specify the non-standard port for SSH to connect to.
Some more detailed notes on the above (sorry, this is bit of a "mind dump" and may not be well organsied, though hopefully it'll help you experiemnt and/or lookup useful examples elsewhere):
- This is called a reverse or remote tunnel because it is more usual to setup redirects fomr the client to the server (not the server to the client as you need here). A local tunnel (client-side to something server-side) is setup using the
-Loption instead of-R(at least with OpenSSH, check your server's documentation for confirmation). - You can give many
-Rand/or-Loptions on the same command line with OpenSSH, so you can setup more than one tunnel in either/any direction using a single SSH connection. - You may need
GatewayPorts yesor similar specified in the server'ssshd_configfor reverse tunnels to work at all. Check your SSHd implementation's documentation for details. - It doesn't matter where the tablet calls from: the tunnel created by the port forward will always point (via the SSH connection) back to its SSH client. You could even point it at some other local resource with a forward like
-R 8888:192.168.42.42:80which will mean connections to 127.0.0.1:8888 on the server will go through the SSH tunnel and hit port 80 on what-ever machine answers to 192.168.42.42 on the network the tablet is currently on (this could even be another remote machine in a completely different location). - You will need the rsync client on the tablet to the server can run it over SSH via the tunnel.
- The above example uses a non-standard port as SSHd is likely to be listening on port 22 on all interfaces on the server. If you are connecting to the server as root then using a port number below 1024 (i.e. 222 instead of 2222) is safer, though you should avoid being connect to remote resources as root where possible. Listending on a port below 1024 is blocked for non-privelaged users by default on Uinx-a-like systems.
- If you don't want to run a SSH daemon on the tablet, you could instead run an instance of rsync in daemon mode instead. The port forward would then be something like
537:127.0.0.1:537or (if you are running rsync in server mode on the server already so port 537 is taken, something like5537:127.0.0.1:537and add-p 5537to the rsync command to tell it the server is not in the standard place). - If your server's SSHd does not listen on port 22 on all the server's interfaces/addresses, then you could use 22 instead of a non-standard port by specifying that the tunnel should attact to a specific interface by adding that address to the start of the
-Rpart, like so:-R 192.168.1.1:22:127.0.0.1:22. The bind address is relative to the server so does not need to be something that is publically routable (in fact an address on a dummy interface even the rest of the local LAN can't see would work). You definitely needGatewayPortson for this to work with OpenSSH. If you don't needGatewayPortson (i.e. if using 127.0.0.1 server-side and a non-standard port and that works with your server's SSHd implementation withoutGatewayPorts yesor equivelant) then leave it off: it is safer this way. - I've assumed IPv4 in all of the above. If your client and server both support it and your networks at each end are appropriately configued, IPv6 addressing will work just as well.
Tunnels through SSH ocnfigured this way can be very powerful once you have played with them and work out what it possible and how to do it, assuming your client and server SSH/SSHd implementations support it all.
add a comment |
I assume you want to be able to connect from anywhere, so you can't garantee what public IP address the tablet will be on (or even if that will allow connections to the tablet from the server, as it is unlikely to be a public address), otherwise you should install a SSH deamon and ash rsync to connect that way. Otherwise, a "reverse tunnel" may be what you are looking for.
If your SSH client on the Android device supports reverse port forwarding then look into using that to build a tunnel. For instance with openssh you can specify -R 2222:127.0.0.1:22 on the command line which would mean things on the server can connect to a SSHd server on the tablet (listening on port 22 on 127.0.0.1 as far as the tablet is concerned) by connecting to port 2222 on 127.0.0.1 (it is important to realise that from the code on the server's PoV 127.0.0.1 is the server, the 127.0.0.1 in the command line is relative the the SSH client). So if that works you can in your server script run something like rsync user@127.0.0.1:/path/to/stuff/on/tablet /path/to/destination/on/server -e 'ssh -p 2222' -a --compress. The -e option is used here to specify the non-standard port for SSH to connect to.
Some more detailed notes on the above (sorry, this is bit of a "mind dump" and may not be well organsied, though hopefully it'll help you experiemnt and/or lookup useful examples elsewhere):
- This is called a reverse or remote tunnel because it is more usual to setup redirects fomr the client to the server (not the server to the client as you need here). A local tunnel (client-side to something server-side) is setup using the
-Loption instead of-R(at least with OpenSSH, check your server's documentation for confirmation). - You can give many
-Rand/or-Loptions on the same command line with OpenSSH, so you can setup more than one tunnel in either/any direction using a single SSH connection. - You may need
GatewayPorts yesor similar specified in the server'ssshd_configfor reverse tunnels to work at all. Check your SSHd implementation's documentation for details. - It doesn't matter where the tablet calls from: the tunnel created by the port forward will always point (via the SSH connection) back to its SSH client. You could even point it at some other local resource with a forward like
-R 8888:192.168.42.42:80which will mean connections to 127.0.0.1:8888 on the server will go through the SSH tunnel and hit port 80 on what-ever machine answers to 192.168.42.42 on the network the tablet is currently on (this could even be another remote machine in a completely different location). - You will need the rsync client on the tablet to the server can run it over SSH via the tunnel.
- The above example uses a non-standard port as SSHd is likely to be listening on port 22 on all interfaces on the server. If you are connecting to the server as root then using a port number below 1024 (i.e. 222 instead of 2222) is safer, though you should avoid being connect to remote resources as root where possible. Listending on a port below 1024 is blocked for non-privelaged users by default on Uinx-a-like systems.
- If you don't want to run a SSH daemon on the tablet, you could instead run an instance of rsync in daemon mode instead. The port forward would then be something like
537:127.0.0.1:537or (if you are running rsync in server mode on the server already so port 537 is taken, something like5537:127.0.0.1:537and add-p 5537to the rsync command to tell it the server is not in the standard place). - If your server's SSHd does not listen on port 22 on all the server's interfaces/addresses, then you could use 22 instead of a non-standard port by specifying that the tunnel should attact to a specific interface by adding that address to the start of the
-Rpart, like so:-R 192.168.1.1:22:127.0.0.1:22. The bind address is relative to the server so does not need to be something that is publically routable (in fact an address on a dummy interface even the rest of the local LAN can't see would work). You definitely needGatewayPortson for this to work with OpenSSH. If you don't needGatewayPortson (i.e. if using 127.0.0.1 server-side and a non-standard port and that works with your server's SSHd implementation withoutGatewayPorts yesor equivelant) then leave it off: it is safer this way. - I've assumed IPv4 in all of the above. If your client and server both support it and your networks at each end are appropriately configued, IPv6 addressing will work just as well.
Tunnels through SSH ocnfigured this way can be very powerful once you have played with them and work out what it possible and how to do it, assuming your client and server SSH/SSHd implementations support it all.
I assume you want to be able to connect from anywhere, so you can't garantee what public IP address the tablet will be on (or even if that will allow connections to the tablet from the server, as it is unlikely to be a public address), otherwise you should install a SSH deamon and ash rsync to connect that way. Otherwise, a "reverse tunnel" may be what you are looking for.
If your SSH client on the Android device supports reverse port forwarding then look into using that to build a tunnel. For instance with openssh you can specify -R 2222:127.0.0.1:22 on the command line which would mean things on the server can connect to a SSHd server on the tablet (listening on port 22 on 127.0.0.1 as far as the tablet is concerned) by connecting to port 2222 on 127.0.0.1 (it is important to realise that from the code on the server's PoV 127.0.0.1 is the server, the 127.0.0.1 in the command line is relative the the SSH client). So if that works you can in your server script run something like rsync user@127.0.0.1:/path/to/stuff/on/tablet /path/to/destination/on/server -e 'ssh -p 2222' -a --compress. The -e option is used here to specify the non-standard port for SSH to connect to.
Some more detailed notes on the above (sorry, this is bit of a "mind dump" and may not be well organsied, though hopefully it'll help you experiemnt and/or lookup useful examples elsewhere):
- This is called a reverse or remote tunnel because it is more usual to setup redirects fomr the client to the server (not the server to the client as you need here). A local tunnel (client-side to something server-side) is setup using the
-Loption instead of-R(at least with OpenSSH, check your server's documentation for confirmation). - You can give many
-Rand/or-Loptions on the same command line with OpenSSH, so you can setup more than one tunnel in either/any direction using a single SSH connection. - You may need
GatewayPorts yesor similar specified in the server'ssshd_configfor reverse tunnels to work at all. Check your SSHd implementation's documentation for details. - It doesn't matter where the tablet calls from: the tunnel created by the port forward will always point (via the SSH connection) back to its SSH client. You could even point it at some other local resource with a forward like
-R 8888:192.168.42.42:80which will mean connections to 127.0.0.1:8888 on the server will go through the SSH tunnel and hit port 80 on what-ever machine answers to 192.168.42.42 on the network the tablet is currently on (this could even be another remote machine in a completely different location). - You will need the rsync client on the tablet to the server can run it over SSH via the tunnel.
- The above example uses a non-standard port as SSHd is likely to be listening on port 22 on all interfaces on the server. If you are connecting to the server as root then using a port number below 1024 (i.e. 222 instead of 2222) is safer, though you should avoid being connect to remote resources as root where possible. Listending on a port below 1024 is blocked for non-privelaged users by default on Uinx-a-like systems.
- If you don't want to run a SSH daemon on the tablet, you could instead run an instance of rsync in daemon mode instead. The port forward would then be something like
537:127.0.0.1:537or (if you are running rsync in server mode on the server already so port 537 is taken, something like5537:127.0.0.1:537and add-p 5537to the rsync command to tell it the server is not in the standard place). - If your server's SSHd does not listen on port 22 on all the server's interfaces/addresses, then you could use 22 instead of a non-standard port by specifying that the tunnel should attact to a specific interface by adding that address to the start of the
-Rpart, like so:-R 192.168.1.1:22:127.0.0.1:22. The bind address is relative to the server so does not need to be something that is publically routable (in fact an address on a dummy interface even the rest of the local LAN can't see would work). You definitely needGatewayPortson for this to work with OpenSSH. If you don't needGatewayPortson (i.e. if using 127.0.0.1 server-side and a non-standard port and that works with your server's SSHd implementation withoutGatewayPorts yesor equivelant) then leave it off: it is safer this way. - I've assumed IPv4 in all of the above. If your client and server both support it and your networks at each end are appropriately configued, IPv6 addressing will work just as well.
Tunnels through SSH ocnfigured this way can be very powerful once you have played with them and work out what it possible and how to do it, assuming your client and server SSH/SSHd implementations support it all.
answered Jan 5 '14 at 0:17
David SpillettDavid Spillett
21.3k3061
21.3k3061
add a comment |
add a comment |
You may have a look at --rsh/-e argument of rsync.
You can replace the rsh with cat or something similar. But you have to add a script at android side which sends the output of your server script to a shell.
Android side:
socat 'EXEC:/bin/bash' 'TCP-LISTEN:20000' &
ssh remoteuser@linuxserver -i path_to_rsa_key -R 20000:127.0.0.1:20000 runthisscript.sh
helper.sh:
#!/bin/sh
host=$2
port=$1
shift 2
{
echo exec "$@"
socat 'STDIN' 'STDOUT'
} | socat '-' "TCP:$host:$port"
runthisscript.sh:
rsync -e './helper.sh 20000' --blocking-io <SRC> <DST>
Can you specify a bit more?
– Abilio Marques
Jan 4 '14 at 22:24
I have edited the answer. But its not complete. If you want better security, you should bindbashdirectly to stdio ofssh. It's not a good idea to bindbashto an ip port, even a local port. And consider add more arguments tosocatto do non-blocking io so that it could be faster.
– Sherwood Wang
Jan 5 '14 at 5:52
add a comment |
You may have a look at --rsh/-e argument of rsync.
You can replace the rsh with cat or something similar. But you have to add a script at android side which sends the output of your server script to a shell.
Android side:
socat 'EXEC:/bin/bash' 'TCP-LISTEN:20000' &
ssh remoteuser@linuxserver -i path_to_rsa_key -R 20000:127.0.0.1:20000 runthisscript.sh
helper.sh:
#!/bin/sh
host=$2
port=$1
shift 2
{
echo exec "$@"
socat 'STDIN' 'STDOUT'
} | socat '-' "TCP:$host:$port"
runthisscript.sh:
rsync -e './helper.sh 20000' --blocking-io <SRC> <DST>
Can you specify a bit more?
– Abilio Marques
Jan 4 '14 at 22:24
I have edited the answer. But its not complete. If you want better security, you should bindbashdirectly to stdio ofssh. It's not a good idea to bindbashto an ip port, even a local port. And consider add more arguments tosocatto do non-blocking io so that it could be faster.
– Sherwood Wang
Jan 5 '14 at 5:52
add a comment |
You may have a look at --rsh/-e argument of rsync.
You can replace the rsh with cat or something similar. But you have to add a script at android side which sends the output of your server script to a shell.
Android side:
socat 'EXEC:/bin/bash' 'TCP-LISTEN:20000' &
ssh remoteuser@linuxserver -i path_to_rsa_key -R 20000:127.0.0.1:20000 runthisscript.sh
helper.sh:
#!/bin/sh
host=$2
port=$1
shift 2
{
echo exec "$@"
socat 'STDIN' 'STDOUT'
} | socat '-' "TCP:$host:$port"
runthisscript.sh:
rsync -e './helper.sh 20000' --blocking-io <SRC> <DST>
You may have a look at --rsh/-e argument of rsync.
You can replace the rsh with cat or something similar. But you have to add a script at android side which sends the output of your server script to a shell.
Android side:
socat 'EXEC:/bin/bash' 'TCP-LISTEN:20000' &
ssh remoteuser@linuxserver -i path_to_rsa_key -R 20000:127.0.0.1:20000 runthisscript.sh
helper.sh:
#!/bin/sh
host=$2
port=$1
shift 2
{
echo exec "$@"
socat 'STDIN' 'STDOUT'
} | socat '-' "TCP:$host:$port"
runthisscript.sh:
rsync -e './helper.sh 20000' --blocking-io <SRC> <DST>
edited Jan 5 '14 at 7:58
answered Jan 4 '14 at 22:02
Sherwood WangSherwood Wang
1635
1635
Can you specify a bit more?
– Abilio Marques
Jan 4 '14 at 22:24
I have edited the answer. But its not complete. If you want better security, you should bindbashdirectly to stdio ofssh. It's not a good idea to bindbashto an ip port, even a local port. And consider add more arguments tosocatto do non-blocking io so that it could be faster.
– Sherwood Wang
Jan 5 '14 at 5:52
add a comment |
Can you specify a bit more?
– Abilio Marques
Jan 4 '14 at 22:24
I have edited the answer. But its not complete. If you want better security, you should bindbashdirectly to stdio ofssh. It's not a good idea to bindbashto an ip port, even a local port. And consider add more arguments tosocatto do non-blocking io so that it could be faster.
– Sherwood Wang
Jan 5 '14 at 5:52
Can you specify a bit more?
– Abilio Marques
Jan 4 '14 at 22:24
Can you specify a bit more?
– Abilio Marques
Jan 4 '14 at 22:24
I have edited the answer. But its not complete. If you want better security, you should bind
bash directly to stdio of ssh. It's not a good idea to bind bash to an ip port, even a local port. And consider add more arguments to socat to do non-blocking io so that it could be faster.– Sherwood Wang
Jan 5 '14 at 5:52
I have edited the answer. But its not complete. If you want better security, you should bind
bash directly to stdio of ssh. It's not a good idea to bind bash to an ip port, even a local port. And consider add more arguments to socat to do non-blocking io so that it could be faster.– Sherwood Wang
Jan 5 '14 at 5:52
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f565083%2frsync-over-active-ssh-connection%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
oreilly.com/pub/h/38
– dmourati
Jan 4 '14 at 22:00