"ssh example.com" hangs but "ssh example.com bash -i" does not

Question

Hello,

everyday I encounter a very strange phenomenon.

From my university internet connection, sshing to my machine ("ssh example.com") works without any problems.

From my home adsl, "ssh example.com" my console gets stuck with this message:

debug1: Server accepts key: pkalg ssh-rsa blen 533
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.

Sometimes it might let me in but in most of the cases not. The funny thing is that if I execute "ssh example.com bash -i" I get logged in immediately.

Answer 1

The difference between the two cases is that "bash -i" does not give you a login shell but just running ssh does. You can "man bash" for details of what a "login shell" is, but the main thing is that it runs /etc/profile and your .bash_profile. Have a look in those files for anything that might be causing a problem.

Answer 2

Maybe the server is out of ptys.

Answer 3

I finally found the source of the problem. It has to do with SSH type of service (ToS) TCP packets.

When you ask for a regular ssh teminal, ssh sets the TCP packet type of service (ToS) to "interactive". My router in my residence blocks those packet types!

Using netcat, the tunneled TCP packets get no type of service directives. Thus, if you tunnel all your ssh traffic through netcat, you reset the ToS of the TCP packets to the default ones.

In .ssh/config, you have to set:

Host *.example.com
    ProxyCommand nc %h %p

So, each time you try to ssh to example.com, netcat will be called and will tunnel the packets.

Answer 4

I've just had the same problem. Try logging in with a different ssh client for more information. Whereas the linux command-line client didn't come back with any useful message, Putty came back with "server refused to allocate pty". I fixed it with mkdir /dev/pts and mount -a. How it got that mucked up in the first place I'm less sure about.

BTW, bash -l should act like a login shell so you should be able to prove Peter Westlake's suggestion correct or incorrect in your case fairly easily.