2

I've been trying to get rsync working for a couple of hours now, but haven't had much luck 😣. I have a Digital Ocean droplet that I would like to send a file via rsync using SSH.

local rsync running on macOS 10.12.6 installed via homebrew
rsync version 3.1.2 protocol version 31

remote rsync running on Debian 8.x installed via apt
rsync version 3.1.1 protocol version 31

I am trying to send a single file from the local macOS box to the remote Debian box (Digital Ocean droplet) The command I am issuing locally in Terminal on macOS
$ rsync -avvvv -e "ssh -p $SSH_PORT_# -v" dummy [email protected]:/home/$USER/www/

Some tidbits,
1) dummy is a single 10MB file on my local system.
2) I can successfully ssh in the remote Digital Ocean with the below command, $ ssh nathan
2.1) I have a "config" file in /Users/$USER/.ssh/
2.2) The contents of the /Users/$USER/.ssh/config

Host nathan
HostName $REMOTE_IP_ADDRESS i.e. 1.2.3.4
User $REMOTE_USERNAME chris
port $SSH_PORT_# 4242
IdentityFile /Users/$USER/.ssh/id_rsa

3) I can also ssh into the remote Digital Ocean droplet with the below command
$ ssh -l $USER -p 4242 $REMOTE_USERNAME example.com

Some output from running the above rsync command,
opening connection using: ssh -p 4242 -v -l $USER example.com rsync --server -vvvvlogDtpre.iLsfxC . /home/$USER/www/ (12 args)
msg checking charset: UTF-8
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/$USER/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to example.com [1.2.3.4] port 4242.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u4
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to example.com:4242 as '$USER'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: compression: none
debug1: kex: client->server cipher: [email protected] MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:REMOVED_KEY
debug1: Host '[example.com]:4242' is known and matches the ECDSA host key.
debug1: Found key in /Users/$USER/.ssh/known_hosts:15
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/$USER/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to example.com ([1.2.3.4]:4242).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending command: rsync --server -vvvvlogDtpre.iLsfxC --log-format=%i . /home/$USER/www/
(Client) Protocol versions: remote=31, negotiated=31

And this is as far I can get using using the above rsync command 😭 If you have any thoughts / suggestions I'd sure love ❤️ to hear them.

cheers 🍺 Chris

3
  • @janos I put that there to omit the actual port that I am using, i.e. when i run the command on my local box (macOS) I specify the actual port I am using on the server with -p 4242. Does that make sense?
    – ipatch
    Commented Dec 19, 2017 at 23:41
  • Have you double checked permissions on the www folder? Sometimes, you can't write to a folder if the parent folders don't share common permissions; maybe try setting the path as ~/www/ instead of /home/$USER/www/ Commented Dec 24, 2017 at 6:01
  • @AnsonWHan thanks for the heads up. I have been hacking ⌨️ away at my config.fish for the past couple of days. And needless to say I put some commands in there that ended up scp / rsync from properly working.
    – ipatch
    Commented Dec 24, 2017 at 21:03

1 Answer 1

1

TLDR; The issue was related to my config.fish file.

How I ended up coming to a resolution.

I decided for a sanity check to create a new user on both machines and test rsync / scp with the newly created user account. Low and behold both ended up working.

Things I ended up trying, rebooting the remote box, starting up sshd in single user mode by passing the -vvvv flag, sifting through the log and seeing nothing related to a file being sent improperly.

The only other computer I have access to locally is a RasPi, so I tried scp / rsync locally to the RasPi, which ended working, so I deduced it had to do something with a configuration file on the server.

You must log in to answer this question.

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