Dear All, I am writing this email because of some observed strange behavior of ssh. I think this is some sort of complement of the issue that was discussed in [1] ([2, 3, 4, 5, 6] were related to the issue). Long story short, I have a client and a server, both running the latest raspbian jessie with all the relevant updates in two different countries (i.e. both OpenSSH_6.7p1 Raspbian-5+deb8u2, OpenSSL 1.0.1k 8 Jan 2015). When I attempt to ssh from one to the other one (direction: country B --> country A) using the command $ ssh -p PPPP user@host then the connection times out after about 2 minutes and I get the error message `Connection closed by <host>`. (So, it is not the message `connection reset by peer` that was present in [1].) Inspecting the configuration for the established link using `-v` I can see that the cipher selected is `aes128-ctr`, the message authentication code (mac) is `umac-64-etm@xxxxxxxxxxx` and the compression is `none`. If I now go ahead and use the command $ ssh -m umac-64-etm@xxxxxxxxxxx -p PPPP user@host quite surprisingly, the key exchange issue that I have above has disappeared and I can connect to the remote machine from country B to country A. Further, specifying only the cipher on command line does not resolve the issue; i.e. using $ ssh -c aes128-ctr -p PPPPP user@host the key exchange times out again. Finally, the combined $ ssh -c aes128-ctr -m umac-64-etm@xxxxxxxxxxx -p PPPPP user@host also works. To make things even weirder, when I attempt to ssh between the two machines in the opposite direction (country A --> country B), then the simple $ ssh -p PPPP user@host command works as expected using exactly the same configuration. That is, I do not have to specify the message authentication code (recall that both machines are raspberry pi's running the latest raspbian jessie, OpenSSH_6.7p1 and OpenSSL 1.0.1k). On another note, lowering the MTU size (which was another workaround for [1]) also allows me to pass successfully the key exchange phase in the direction where I normally have an issue (that is, country B --> country A). The maximum MTU size that would allow me to pass the key exchange negotiation was 1458 (that is, with a size of 1459 the key exchange got stuck). My first attempt to resolve the situation was in Raspberry Pi Stack Exchange in thread [7]. Since the issue was not resolved there, I posted the issue in Super User Stack Exchange in thread [8]. It was this thread that made me aware of the issue in [1] where by lowering the MTU size was a viable solution. However, this may not be the only issue here, because, as explained above, automatic configuration of MAC leads to failure (but then again, only in one direction of establishing the link). If you need more details on the output or the configurations that I am using I am happy to provide you with all the relevant information. Meanwhile, if you would like to read an extended version with debug information (`ssh -vv ...`), I would suggest [8] which was written more recently and I think has a better description of the problem. Best regards, Dimitris References [1] ssh 'connection reset by peer' problem since 5.8p1, url: http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-March/029432.html [2] The mysterious case of broken SSH client (“connection reset by peer”), url: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/ [3] Can't login anymore: Read from socket failed: Connection reset by peer, url: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493 [4] Connecting to older ssh version has cipher negotiation problem, url: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612607 [5] FS#22897 - [openssh] SSH is falling to connect to some server Read from socket failed: Connection reset by peer, url: https://bugs.archlinux.org/task/22897 [6] ssh client problem: Connection reset by peer [closed], url: http://serverfault.com/questions/265244/ssh-client-problem-connection-reset-by-peer [7] Can not ssh on remote host, url: http://raspberrypi.stackexchange.com/questions/48089/can-not-ssh-on-remote-host [8] Strange ssh connection issue, url: http://superuser.com/questions/1082529/strange-ssh-connection-issue/ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
