SSH 斷管，消息驗證碼不正確
我已經設置了一個 Ubuntu 伺服器，我計劃使用它來備份我的 macbook air
rsync。但是每次我使用rsync，甚至scp，連接都會斷開，並出現以下錯誤之一：packet_write_wait: Connection to 192.168.1.202: Broken pipe packet_write_poll: Connection to 192.168.1.202: Broken pipe packet_write_poll: Connection to 192.168.1.202: Protocol wrong type for socket現在我已經搜尋了類似的其他問題，通常人們在會話超時的長備份中遇到這個問題。對我來說，這總是在開始文件傳輸後 10 秒內發生。我使用 scp 和 rsync 得到了同樣的錯誤。我想這可能是由於網路連接錯誤，但我很難相信我與同一 LAN 上的伺服器的連接如此不穩定。有人有想法麼？
我使用的導致錯誤的命令範例：
scp -r /Users/Matt/Documents matt@192.168.1.202:/media/matt/MattsBackups/ /usr/local/bin/rsync -av -e ssh /Users/Matt/Documents matt@192.168.1.202:/media/matt/MattsBackups/今天我又做了一些測試，奇怪的是，它在我的區域網路之外執行得相當可靠。所以我從我的家庭網路中再次嘗試，它仍然無法正常工作。
跑步
grep 'sshd' /var/log/auth.log伺服器上顯示以下錯誤
fatal: ssh_dispatch_run_fatal: Connection from <My IP> port 49870: message authentication code incorrect關於我的設置的一些更詳細的資訊：
Macbook Air OS X 10.11.5 OpenSSH_6.9p1, LibreSSL 2.1.8 rsync version 3.1.2 protocol version 31 Ubuntu Server OpenSSH_7.2p2 Ubuntu-4ubuntu1, OpenSSL 1.0.2g-fips 1 Mar 2016我確實注意到了 ssh 版本的不同，但我希望這不會成為問題。我可以嘗試使用自製軟體安裝更新版本。
更新：
好的，我剛剛用自製軟體更新了 ssh 到
OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016這似乎與 Ubuntu 盒子上使用的版本相同。但是，當我執行命令時，Rsync 仍然會導致錯誤。這是我嘗試使用 ssh -v 標誌的命令：
/usr/local/bin/rsync -a -e '/usr/local/bin/ssh -v -c aes128-ctr -m hmac-sha1' /Users/Matt/Documents matt@192.168.1.202:/media/matt/MattsBackups/輸出是：
OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016 debug1: Reading configuration data /usr/local/etc/ssh/ssh_config debug1: Connecting to 192.168.1.202 [192.168.1.202] port 22. debug1: Connection established. debug1: identity file /Users/Matt/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /Users/Matt/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/Matt/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/Matt/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/Matt/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/Matt/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/Matt/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/Matt/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu1 debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu1 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 192.168.1.202:22 as 'matt' 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: aes128-ctr MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+zkrXNJENs5EobFwHa8wpMDe6zPDfj975qLcPp4b4sg debug1: Host '192.168.1.202' is known and matches the ECDSA host key. debug1: Found key in /Users/Matt/.ssh/known_hosts:1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /Users/Matt/.ssh/id_rsa debug1: Server accepts key: pkalg rsa-sha2-512 blen 279 debug1: Authentication succeeded (publickey). Authenticated to 192.168.1.202 ([192.168.1.202]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: Sending command: rsync --server -logDtpre.iLsfxC . /media/matt/MattsBackups/MacAir/ debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Connection to 192.168.1.202 closed by remote host. Transferred: sent 145304, received 13032 bytes, in 0.1 seconds Bytes per second: sent 1373019.8, received 123143.2 debug1: Exit status -1 rsync: [sender] write error: Broken pipe (32) rsync error: error in socket IO (code 10) at io.c(820) [sender=3.1.2]
作為最後的手段，我從一台 Windows 98 PC 上找到了一張舊的 10/100 乙太網卡，並將其安裝在伺服器中。配置後，我沒有更多的錯誤，大約 30 GB 的數據。我猜內置的乙太網晶片組不適用於 ubuntu。或者我以某種方式錯誤地配置了它。
編輯：雖然我從未找到問題的根本原因，但請務必查看@sourcejedi 答案下的評論執行緒。非常感謝@sourcejedi、@sneep 和@dentarg。
這可能是您的 SSH 中的錯誤。隨著時間的推移，已經有幾個這樣的例子。（您絕對應該發布兩端使用的確切版本）。
http://www.alcatelunleashed.com/viewtopic.php?t=25294
我無法弄清楚為什麼遠端網路路徑會更可靠，或者有什麼建議可以解決這個問題。它可能是由錯誤的網路盒引起的……
如果您的 Ubuntu 伺服器是最近安裝的並且安裝了所有可用的更新，我會更加懷疑 Mac 客戶端上的軟體，因為它很舊並且受到類似這樣的錯誤的影響。
您可以測試不同的 MAC 等。例如
scp -o MACs=hmac-md5注意 hmac-md5 不像 md5 那樣被認為是弱的（在 ssh 的上下文中）（例如在 HTTPS 證書的上下文中）。我主要希望它比例如慢
umac-64-etm@openssh.com。但是，如果可以的話，最好使用-etm模式。這些連結建議您可以選擇較舊的選項
MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160它將避免某些錯誤。找到滿意的東西後，您可以在
/etc/ssh_config.
Cipher也可能是問題所在。如果您使用的是 aes-gcm egaes128-gcm@openssh.com，則可能根本沒有單獨的 MAC。因此，您至少需要ssh通過添加-v命令並查找它說它實際使用的 MAC 來確保正在執行的操作。