On Sun, Aug 2, 2015 at 7:02 AM, Quartz <qua...@sneakertech.com> wrote: > I know how ps works :)
Ok, good, then the problem lies elsewhere... > On OSX, an outbound ssh connection spawns a single 'ssh' process, which is a > child of bash. bash is a child of login. login is a child of Terminal. Perhaps here. The point was to use ps on the *server* not on the client. If you were not seeing sshd and you know how to use ps, that must mean you were using ps on your local machine rather than on the remote machine. But the question I was asking was: if you can establish one connection to the remote machine can you still duplicate the problem. And, unfortunately, it looks like I assumed you understood my thought process when I was not being clear about that. I was guessing that the problem might be a problem on the server. This would account for why you only see the problem there, rather than at other sites. So I was thinking you should use ps *on that server* to see if you could see signs of another connection attempt reaching it and then for some reason failing to give you an interactive shell. In other words, it might be that there's some race condition on the server that you sometimes fail to reach, such that ssh -v slows things down just enough to avoid the race. If that is the case, since you said the connection hangs, it's possible that the problem exists in a subprocess of sshd rather than in sshd itself. And that is what I was suggesting you test. Of course, it's also possible that you're seeing network problems, in which case something like tcpdump would be a better source of clues (assuming that you can trace all the way to the server on a good day). And, it's also possible that the problem is a race within the remote sshd (or maybe even the remote kernel) and that that would prevent spawning any subprocesses. In either of those cases, my suggestion would not result in any new information - but it would still be the case that a negative result from testing for new processes would tell you not to concern yourself with my guess. >> Or: ps -lx | grep 'ssh[d]' > > Not sure what OS / version of grep you're using. On OSX this yields no > output even when ssh processes are running. If I shorten the regex to just > 'ssh' I see the ssh process and ssh-agent which I mentioned above. If you are on an openbsd machine which is running sshd (either because it's running in daemon mode, or because you have an ssh connection into it), this will show you some information about the sshd process(es). I put the [] around the d so that the grep itself will not show up, and I put the '' around the regexp to eliminate the tiny chance that you would have a file named sshd in your current directory. The point of this exercise would be to help isolate where your connection attempts stall. Thanks, -- Raul
