I am using rsync to copy files to a target server when I connect to it using ssh. To do this I have the following in my ssh config file:-

ControlMaster auto
ControlPath ~/.ssh/%r@%h:%p
host dns
   LocalCommand rsync --update -a -e "ssh -o PermitLocalCommand=no" ~/.cfg/ dns:.cfg/ &

The ControlMaster bit means that after one ssh to the server subsequent ssh connections don't ask for the password. Thus the rsync runs without asking for the password.

The oddity is that it won't work without the & at the end of the LocalCommand line in the config file. Why does it need this? Without the & the login just hangs after entering the password and if you CTRL/C it you get an rsync error as it's been interrupted by the CTRL/C and the connection fails. The rsync copy only takes a fraction of a second, the hang is not due to rsync taking a long time.

I took quite a while to find how to make this work, initially without the & it just hung, as I said. I then put the rsync command in a script and called that, it still hung. I found that starting a terminal from the script and running the rsync in that worked OK. Then I went backwards and put the & after the rsync in the script and that worked, finally I got to what I have above.

It's not a big issue, I'm happy with the way it works, but I'd love to kow why the & is needed.

This is all on Linux, both ends running xubuntu/ubuntu.

  • This is interesting. I probably won’t be able to answer this, but I’m curious (and the answers to these questions may help somebody else to answer it). (1) What happens when you wait long enough for the rsync to finish, and then type Ctrl+C — has the rsync finished? Has it started? (2) Try replacing the rsync command with a script that does something like for i in {1..42}; do echo "$i"; sleep 1; done (maybe redirected to a file) and experiment with that. What happens? Oct 26, 2018 at 0:43
  • No, the rsync is just blocked for ever. Oct 27, 2018 at 14:19

1 Answer 1


Possibly answer in this blogpost:

Finally, there is something of an annoyance with ControlMaster, and it’ll probably confuse you mightily when you first come across it. Because all of your SSH sessions are multiplexed down a single TCP connection initiated by the first SSH session, that first session must stay alive until all of the other sessions are complete. This problem will manifest itself as an apparent “hang” when you log out of the remote session that is acting as the master — instead of getting your local prompt back, SSH will just sit there. If you Ctrl-C or otherwise kill this session, all of the other sessions you’ve got setup to that server will drop, so don’t do that. Instead, when you logout of all the other sessions, the master will then return to the local prompt.

I've solved similar problem by adding -S none to list ssh options:

LocalCommand rsync --update -a -e "ssh -o PermitLocalCommand=no -S none" ~/.cfg/ dns:.cfg/
  • But this seems to be the opposite of what Chris Green is experiencing. Oct 26, 2018 at 0:25
  • Yes, quite, I have come across this 'annoyance' but it's not whats happening with what I've described above. The master connection is still open and futher ssh connections succeed without asking for password. Oct 27, 2018 at 14:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .