This sounds like perhaps a bad NAT instance inside VPC? -- ~*~ StormeRider ~*~
"Every world needs its heroes [...] They inspire us to be better than we are. And they protect from the darkness that's just around the corner." (from Smallville Season 6x1: "Zod") On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS On Mon, Oct 6, 2014 at 1:04 PM, Phil Pennock <lopsa-t...@spodhuis.org> wrote: > On 2014-10-06 at 10:41 -0600, Yves Dorfsman wrote: > > A Linux instance becomes unreachable via ssh from some ip addresses. If > you > > try to ssh from those addresses, it just hangs, for ever, until to > ctrl-c out > > of it. Yet you can ssh from other ip addresses without any problem. > > > > The ip addresses that work and that don't seem random, some are outside > AWS, > > some inside, even on the same subnet. When we run in DEBUG3 mode, we see > that > > the client sent it's key, while the server waits for the said key, and > sits > > there waiting. The few similar issues (ssh hanging at key exchange) we > found > > when googling were solved by changing MTU! > > Sounds perfectly reasonable. > > You have a virtualized network; with large-scale clustered switches, the > path between two hosts on the "same" network can vary based upon source > and destination IPs. One misconfigured switch (or bad link) ends up > only affecting those paths: you no longer have a host being "on the > network" or "not on the network". > > With a broken path and something dropping ICMP fragmentation needed > packets, you lose packets which exceed the path MTU. If you want to > work reliably, revisit the broken firewalls and packet filters, to let > Path MTU Discovery (PMTUD) work. > > So: virtualized network, and something filtering out ICMP packets which > it shouldn't be, between the source and destination hosts, so all TCP > flows between them break as soon as you try to send too large a packet. > As soon as someone has a Ridiculously Large Key the "too large" happens > when signing/sending the pubkey offer from the client to the server. > > Regards, > -Phil > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
