SSHが壊れたパイプ、メッセージ認証コードが正しくない
rsyncを使用してmacbook airのバックアップに使用する予定のUbuntuサーバーをセットアップしました。しかし、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 [email protected]:/media/matt/MattsBackups/
/usr/local/bin/rsync -av -e ssh /Users/Matt/Documents [email protected]:/media/matt/MattsBackups/
今日はさらにいくつかのテストを行いましたが、不思議なことに、LANの外部からかなり信頼性高く機能していました。そのため、ホームネットワーク内から再試行しましたが、それでも機能しません。
ランニング
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バージョンの違いに気づきましたが、それが問題にならないことを望んでいました。自作で新しいバージョンをインストールしてみることができます。
更新：
OK私は自作で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 [email protected]:/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: [email protected]
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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] 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証明書のコンテキストで）。主に遅いと思います。 [email protected]。ただし、可能であれば-etmモードを使用することをお勧めします。
リンクは、古いオプションを優先できることを示唆しています
MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
特定のバグを回避します。満足するものが見つかったら、/etc/ssh_configで設定できます。
Cipherも問題である可能性があります。 aes-gcmを使用している場合[email protected]、おそらく個別のMACがまったく存在しない可能性があります。したがって、少なくともsshがコマンドに-vを追加し、実際に使用していると表示されているMACを探すことで、何が実行されているかを確認する必要があります。