SSH broken pipe, message authentication code incorrect

Well as a last resort, I found an old 10/100 ethernet card from a windows 98 PC, and installed it in the server. After configuring it, I have had no more errors, over about 30 GB of data. I guess the built-in ethernet chipset didn't work well with ubuntu. Or I had somehow configured it incorrectly.

Edit: While I never found the root cause of my problem, be sure to check out the comment thread under @sourcejedi's answer. Big thanks to @sourcejedi, @sneep and @dentarg.

It could be a bug in your SSH. There have been several examples of this over time. (You should definitely post the exact versions used at either end).

http://www.alcatelunleashed.com/viewtopic.php?t=25294

I can't work out why a remote network path would be more reliable, or any suggestion to work on that. It can be caused by buggy network boxes though...

http://community.ubnt.com/t5/EdgeMAX/clone-from-gitlab-com-through-ER-ssh-dispatch-run-fatal-message/td-p/1448285

If your Ubuntu server is recently installed and has all available updates installed, I'd be more suspicious of the software on the Mac client, that it's old and affected by some bug like this.

You could test different MACs etc. E.g.

scp -o MACs=hmac-md5

Note hmac-md5 is not considered weak (in the context of ssh) in the same way md5 is (e.g. in the context of HTTPS certificates). I expect mainly it's slower than e.g. [email protected]. However it should be better to use -etm modes if you can.

The links suggest you can prefer older options

MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160

and it will avoid certain bugs. Once you find something you're happy with, you can configure it in /etc/ssh_config.

The Cipher could also be the problem. If you're using aes-gcm e.g. [email protected], maybe there's not a separate MAC at all. So you at least need to make sure of what ssh is doing by adding -v to your commands and looking for the MAC it says it's actually using.