Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am having a strange issue with ssh. I am getting a

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

every time I connect to a server. Then I cleared the known_hosts file and connect again. After 2 to 3 minute I access the server again and the WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! again came. The ssh connection automatically aborts after connection. I am sure that my IP and ssh keys are not changing. I have checked in server and both id_rsa and id_rsa.pub key is not changing. My server has also become very slow. Also I have tuned my server against sync attacks and still no result. Can anyone help me?


The issue still exists. The hosting company told me that the network doesn't have any issue. When an ssh connection is terminated due to this strange problem, actually the user doesn't gets logs out. When I enter a new session using ssh, I can see the old user stills logged in by typing the W command. If this user also disconnects and when I relogin I can see 3 users loged in means users doesn't gets logged out.

These are the logs when connection is disconnected by the server

Jul 31 10:28:33 cl-t229-203cl sshd[2082]: debug1: Forked child 6551.
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: Set /proc/self/oom_score_adj to 0
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: inetd sockets after dupping: 3, 3
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: Connection from 173.45.65.243 port 56944
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: Client protocol version 2.0; client software version OpenSSH_5.3
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: match: OpenSSH_5.3 pat OpenSSH*
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: Enabling compatibility mode for protocol 2.0
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: Local version string SSH-2.0-OpenSSH_5.3
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: permanently_set_uid: 74/74
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: list_hostkey_types: ssh-rsa
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: SSH2_MSG_KEXINIT sent
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: SSH2_MSG_KEXINIT received
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: kex: client->server aes128-ctr hmac-md5 none
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: kex: server->client aes128-ctr hmac-md5 none
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: SSH2_MSG_NEWKEYS sent
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: expecting SSH2_MSG_NEWKEYS
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: SSH2_MSG_NEWKEYS received
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: KEX done
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: userauth-request for user root service ssh-connection method none
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: attempt 0 failures 0
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: PAM: initializing for "root"
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: PAM: setting PAM_RHOST to "173.45.65.243"
Jul 31 10:28:33 cl-t229-203cl sshd[6551]: debug1: PAM: setting PAM_TTY to "ssh"
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: userauth-request for user root service ssh-connection method keyboard-interactive
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: attempt 1 failures 0
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: keyboard-interactive devs
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: auth2_challenge: user=root devs=
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: kbdint_alloc: devices 'pam'
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: debug1: auth2_challenge_start: trying authentication method 'pam'
Jul 31 10:28:33 cl-t229-203cl sshd[6552]: Postponed keyboard-interactive for root from 173.45.65.243 port 56944 ssh2
share|improve this question
1  
I would never clear out my known_hosts file. –  Simon Richter Jul 29 '13 at 12:52
    
When you say that the hosting company told you that "the network doesn't have any issue", what exactly did you ask them, what did they check for, and how? –  MadHatter Jul 31 '13 at 5:17
add comment

1 Answer

The combination of disconnection (TCP stream desynchronisation) and change of keys suggests very strongly that you've got two devices with the same IP address. Is this server on your LAN, or is it something you're accessing through a router?

Edit: I'd definitely raise this with the hosting company. There's a possibility that someone's misunderstood an address allocation, or there's a typo in /etc/sysconfig/network-scripts/ifcfg-eth0 (or OS-equivalent file), or the hosting company has stuffed up. But you won't know until you talk to them.

If the server were local, you could look in your ARP cache to see if the MAC address of the server was changing after each dropout. But since it's remote, they'd have to do that for you, as well.

share|improve this answer
    
The server is a remote server from a hosting company. –  user183393 Jul 29 '13 at 8:13
    
Hi, I don't think it is an issue with hardware address. Because each time when I connected to this machine my hardware address seems to be same. The issue is something strange. –  user183393 Jul 29 '13 at 15:27
1  
I didn't say it was "hardware address". I said it was two pieces equipment with the same IP address; specifically, another piece of equipment at your server provider with the same IP address as your server's. –  MadHatter Jul 29 '13 at 16:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.