How to properly use rsync Push with SSH on local macOS to remote Debian

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 $USER@example.com:/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: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com 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 no-more-sessions@openssh.com
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

Answer

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.