SSH not responding right after authentication

Have you opened port 22 on router/firewall?

Also the log seems fine. Please look in /etc/passwd. Look at username's line and the line should be in that format:

uname:x:userid:groupid:optional comment:home dir:shell(for example /bin/bash, if it's /sbin/nologin or /bin/false, you need to change it to /bin/bash or /bin/ksh)

Select allOpen in new window

yes

we are able to login from LAN, there is no problem with passwd file.

Another issue, on your server you use 7 years old version of ssh. So that might be te problem. On our server ssh -v returns:
OpenSSH_5.8p1-hpn13v10, OpenSSL 1.0.0d 8 Feb 2011
While yours does:
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
I would update it. This is an very old version and probably has many security holes and bugs.

Could you please paste output of below given commands.

#ip a

# iptables -L -v

here it is:

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:56:81:73:7c brd ff:ff:ff:ff:ff:ff
    inet 172.16.5.113/22 brd 172.16.7.255 scope global eth0
    inet6 fe80::250:56ff:fe81:737c/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noqueue
    link/sit 0.0.0.0 brd 0.0.0.0


attached file has iptables -L -v output
iptables

It may be a reverse DNS lookup issue. Disable reverse DNS for SSH.

http://linux-tips.org/article/92/disabling-reverse-dns-lookups-in-ssh

Already tried that option, but no luck

Once try to flush the iptable and then connect with ssh.

# iptables -F

or

# iptables --flush

no luck

Did you try adding -u0 to the SSHD statup?

yes, tried with -u0 and "usedns no". no luck

Some times it even prints Last login message and hangs

I suppose that the line "Last login..." means you're already in. I'd suspect some shell startup files (.profile, /etc/profile and similar) for doing something strange, like "xauth -" when not forwarding X11).

How long does the session hang?  Does it eventually become usable or disconnect?

You've mentioned a VPN.  Does this problem only happen when going through the VPN?  Does the system hang when connecting directly to console (using a directly-attached keyboard + mouse)?

This may be worth looking at, since you're running v3.8, which may have been an upgrade::: http://www.openssh.org/faq.html#3.3

>> I suppose that the line "Last login..." means you're already in. I'd suspect some shell startup files
>>(.profile, /etc/profile and similar) for doing something strange, like "xauth -" when not forwarding X11).

When we connect from LAN It is working, we are able to work normally, if there is any problem with .profile it should not work in LAN.

>>How long does the session hang?  Does it eventually become usable or disconnect?

It hangs till ssh timeout, we are not able to kill the session with ctrl+c

>>You've mentioned a VPN.  Does this problem only happen when going through the VPN?  Does the >>system hang when connecting directly to console (using a directly-attached keyboard + mouse)?

yes only happens via VPN(stange!!), from LAN it is fine. It is a VM and on console it is fine.

First, let me suggest that you upgrade your version of SSH, it seems very old.

With that out of the way, adding this option when SSH'ing:

ssh -o GSSAPIAuthentication=no

Select allOpen in new window

>>ssh -o GSSAPIAuthentication=no

not working ):

last lines of sshd debug log:

debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 3
debug3: mm_request_receive entering
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug3: tty_parse_modes: SSH2 n_bytes 16
debug3: tty_parse_modes: 3 127
debug3: tty_parse_modes: ispeed 38400
debug3: tty_parse_modes: ospeed 38400
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: PAM: setting PAM_TTY to "/dev/pts/2"
debug2: fd 4 setting TCP_NODELAY
debug2: channel 0: rfd 10 isatty
debug2: fd 10 setting O_NONBLOCK
debug2: fd 9 is O_NONBLOCK
debug1: Setting controlling tty using TIOCSCTTY.

hmm, check that you can login via ssh, and also
try recreate keys, rsa, etc

also remove .ssh/known_host file.

and check that client version and severversion of SSH is nearly same..

Hi, it is MTU issue some where in the network MTU is less than our linux server MTU.