Yves Dorfsman writes:
> Yes, that was DEBUG3 on the server (in /etc/ssh/sshd_config), and -vvv on the
> client.
Oops, sorry for missing that.
> As mentioned earlier, the server waits for the client to send the key, the
> trace is totally identical to the same trace for a working client, except
> that
> it stops waiting to receive a key while the other obviously receive the key
> and keeps going.
I guess the other thing that occurs to me is whether something is
preventing the server from accessing the public key for the account
that's authenticating, or preventing the client from accessing the
private key for the account. You might even have to go deeper and use
tools like tcpdump to trace the network traffic or strace to look at
what system calls are being issued (or more importantly, which ones are
stalling) by the client and server processes.
> On 2014-10-06 11:56, Steve VanDevender wrote:
> > Yves Dorfsman writes:
> > > Yes, DEBUG3.
> > >
> > > The trace from a working client and a non-working client are identical,
> > except
> > > that the non-working one stops when it gets to the point of waiting to
> > receive
> > > the key from the client.
> > >
> > > ssh -vvvv on the client sides hangs at "key sent"...
> >
> > Perhaps you should try running sshd in debug mode on the server? If you
> > are uncomfortable taking down the server's main sshd for testing
> > ("sshd -d" processes only one connection at a time), you could also try
> > running an instance on an alternate port ("sshd -d -p 2222") and have
> > the problematic clients try to connect to that port
> > ("ssh -p 2222 user@server").
> >
> > > On 2014-10-06 11:36, Derek Murawsky wrote:
> > > > Have you run the server(s) with debugging turned up? If you're seeing
> > this
> > > > regularly, it might make sense to run with debug logging for a week
> > and see
> > > > what your server is seeing. Have all your clients retry with
> > debugging up as
> > > > well, and then compare notes next time this happens.
> > > > At a guess, it sounds almost like sshd is hanging. Otherwise it
> > should close
> > > > out on its own after about 30-90 seconds from a TCP timeout.
> > > > -D
> > > >
> > > > On Mon, Oct 6, 2014 at 12:41 PM, Yves Dorfsman <y...@zioup.com
> > > > <mailto:y...@zioup.com>> wrote:
> > > >
> > > >
> > > > We've run into this weird AWS issue 3 times now in a week, never
> > seen it
> > > > before:
> > > >
> > > > 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!
> > > >
> > > > The only resolution we have found so far is to stop/start the
> > instance and get
> > > > a new ip (tbh, we haven't tried to just reboot).
> > > >
> > > > Has anybody run into this? Any idea what's going on?
> > > >
> > > > --
> > > > Yves.
> > > > _______________________________________________
> > > > Tech mailing list
> > > > Tech@lists.lopsa.org <mailto: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/
> > > >
> > >
> > >
> > > --
> > > Yves.
> > > _______________________________________________
> > > 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/
> >
>
>
> --
> Yves.
_______________________________________________
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/
