The point was to use ps on the *server* not on the client.
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.
Ah ok. Yes I totally misunderstood you- I thought you meant check ps on the client to see if it was actually spawning an ssh process.
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.
That's possible. I'm not convinced it's on their end though, you'd think they'd have noticed by now ssh connections hanging all the time.
Of course, it's also possible that you're seeing network problems,
They do some weird stuff with their systems sometimes. Half their stuff is in house and the other half is cloud, and it's not always coherent. Additionally, there's always the possibility that I've somehow configured my firewalls in a weird way.
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).
Traceroute specifically doesn't yield much: outside of my ISP it bounces off over a dozen boxes with no host names before disappearing into a black hole (magic cloud issues I'm sure). Filtering with tcpdump can be annoying since what I filter for isn't always what comes back due to all the dns redirection. I do seem to be able to see at least most of the packets though I think.
If you are on an openbsd machine which is running sshd
OK. This works on their linux server.
