Eu configurei um servidor Ubuntu que eu planejo usar para fazer backup do meu macbook air usando rsync . Mas toda vez que eu uso rsync , ou mesmo scp , a conexão cai, com um dos seguintes erros:
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
Agora eu pesquisei outras perguntas como esta, e geralmente as pessoas têm esse problema com backups longos em que a sessão expira. Para mim isso sempre acontece dentro de 10 segundos após iniciar a transferência de arquivos. Eu recebo os mesmos erros usando scp e rsync. Eu acho que poderia ser devido a uma conexão de rede com defeito, mas acho difícil acreditar que minha conexão com o servidor na mesma LAN é instável. Alguém tem alguma ideia?
Exemplos dos comandos que usei que resultam nos erros:
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/
Eu fiz mais alguns testes hoje, e por incrível que pareça, ele estava funcionando de forma confiável fora da minha LAN. Então, tentei novamente dentro da minha rede doméstica e ainda não funciona.
Rodando
grep 'sshd' /var/log/auth.log
no servidor mostra o seguinte erro
fatal: ssh_dispatch_run_fatal: Connection from <My IP> port 49870: message authentication code incorrect
Algumas informações mais detalhadas sobre minha configuração:
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
Eu notei a diferença nas versões ssh, mas esperava que não fosse um problema. Eu posso tentar instalar uma versão mais nova com o homebrew.
ATUALIZAÇÃO:
OK, acabei de atualizar o ssh com homebrew para
OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016
que parece ser a mesma versão usada na caixa do Ubuntu. No entanto, o Rsync ainda resulta no erro quando eu executo o comando. Heres o comando que eu tentei com o sinalizador 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/
A saída é:
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]
Como último recurso, encontrei uma placa ethernet 10/100 antiga de um computador com Windows 98 e a instalei no servidor. Depois de configurá-lo, não tive mais erros, em mais de 30 GB de dados. Eu acho que o chipset ethernet integrado não funcionou bem com o Ubuntu. Ou eu tinha de alguma forma configurado incorretamente.
Pode ser um bug no seu SSH. Houve vários exemplos disso ao longo do tempo. (Você deve definitivamente postar as versões exatas usadas nos dois lados).
Não sei por que um caminho de rede remoto seria mais confiável ou qualquer sugestão para trabalhar nisso. Pode ser causado por caixas de rede com bugs embora ...
Se o seu servidor Ubuntu foi recentemente instalado e tem todas as atualizações disponíveis instaladas, eu ficaria mais desconfiado do software no cliente Mac, que ele é antigo e afetado por algum bug como este.
Você pode testar diferentes MACs etc. Por exemplo,
scp -o MACs=hmac-md5
Nota: hmac-md5 não é considerado fraco (no contexto do ssh) da mesma forma que md5 é (por exemplo, no contexto de certificados HTTPS). Espero que seja mais lento do que, por exemplo. %código%. No entanto, deve ser melhor usar os modos [email protected] , se puder.
Os links sugerem que você pode preferir opções mais antigas
MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
e evitará certos erros. Quando você encontrar algo com o qual está feliz, poderá configurá-lo em -etm .
O /etc/ssh_config também pode ser o problema. Se você estiver usando aes-gcm, por exemplo Cipher , talvez não exista um MAC separado. Então, pelo menos, você precisa ter certeza do que o [email protected] está fazendo adicionando ssh aos seus comandos e procurando pelo MAC que está sendo usado.
Tags ssh networking rsync scp osx