Dear friends ,

I got a strange problem . Recently , I cannot connect to my Linux server from my windows using SSH (secure Shell ) Software suddenly . When i got connected then firstly it prompt for pasword and then I press my user also root user's password . But at that moment it hangs for a long time and cannot response anything . I dont understand the problem ..... Plz give me solution plz ...


Here i also mention that , there have no security changes in my server

Try running the ssh client in verbose mode to see how far through the login process you get.

I'm not sure about Windows ssh clients, but with the openssh client which runs on Linux you can add the -v option several times to display verbose information while the connection and login are working.

We need more information. You can stop the SSH daemon on the Linux machine and run it in interactive mode from the command line with either "-d" or "-v" (check your man pages) to produce debugging output. That will show you what is happening on the server, which is usually the place where handshaking and authentication problems occur.

Thx matthewg42 ,

I m trying to do ssh in using 'v' option but still I cannot connect to that REMOTE SERVER .
Here the ssh command output :

[root@server ~]# ssh -v 69.88.10.114 -l rashedf
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 69.88.10.114 [69.88.10.114] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes108-cbc hmac-md5 none
debug1: kex: client->server aes108-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host '69.88.10.114 (69.88.10.114)' can't be established.
RSA key fingerprint is e8:99:0c:b9:f7:39:8a:39:90:00:91:31:91:49:ae:c2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '69.88.10.114' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
rashedf@69.88.10.114's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

Plz tell me some solutions plz ..

From the output of ssh -v we can see that the authentication succeeded, so we can rule out some problem with that.

What happens next? Nothing at all? If so, it seems like the remote host is either having problems starting a shell, or perhaps there is something weird going on in the shell rc files. Did the .bashrc / .profile or similar file get edited at some point?

In any case, do you have physical access to the machine? If so, can you get a normal shell on it locally?

Try doing the log in, waiting a minute or so after it seems to be stuck, and then pressing control-C. If there is something in the .bashrc which is taking a long time to execute, pressing control-C might break out of that to a shell, and then you can edit the rc files and try to work out what is causing the lockup.