Странная проблема SSH с ключом SSH

1

У меня странная проблема с SSH. Я получаю

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

каждый раз, когда я подключаюсь к серверу. Затем я очистил файл known_hosts и снова подключился. Через 2-3 минуты я снова получаю доступ к серверу и WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!снова пришел. Соединение ssh автоматически прерывается после соединения. Я уверен, что мой IP и ssh ключи не меняются. Я проверил на сервере, и ключ id_rsa и id_rsa.pub не меняется. Мой сервер также стал очень медленным. Кроме того, я настроил свой сервер против атак синхронизации и до сих пор не дал результата. Может кто-нибудь помочь мне?


Проблема все еще существует. Хостинговая компания сказала мне, что у сети нет проблем. Когда соединение ssh прерывается из-за этой странной проблемы, пользователь фактически не выходит из системы. Когда я вхожу в новый сеанс с помощью ssh, я вижу, что старые пользовательские кадры вошли в систему, набрав команду W. Если этот пользователь также отключается, и когда я перезагружаюсь, я вижу, что 3 пользователя вошли в систему, значит, пользователи не вышли из системы.

Это логи, когда сервер разрывает соединение

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
user183393
источник
2
Я бы никогда не очистил свой known_hostsфайл.
Саймон Рихтер
1
Когда вы говорите, что хостинговая компания сказала вам, что « у сети нет проблем », что именно вы им задали, что они проверяли и как?
MadHatter

Ответы:

6

Комбинация разъединения (десинхронизация потока TCP) и смена ключей очень убедительно свидетельствуют о том, что у вас есть два устройства с одинаковым IP-адресом. Этот сервер находится в вашей локальной сети, или к нему вы подключаетесь через маршрутизатор?

Изменить: я бы определенно поднял это с хостинговой компанией. Есть вероятность, что кто-то неправильно понял распределение адресов, или есть опечатка /etc/sysconfig/network-scripts/ifcfg-eth0(или файл, эквивалентный ОС), или хостинговая компания запуталась. Но ты не узнаешь, пока не поговоришь с ними.

Если бы сервер был локальным, вы могли бы заглянуть в свой ARP-кеш, чтобы увидеть, меняется ли MAC-адрес сервера после каждого отключения. Но так как это далеко, им придется сделать это и для вас.

Безумный Шляпник
источник
Сервер является удаленным сервером от хостинговой компании.
user183393
Привет, я не думаю, что это проблема с аппаратным адресом. Потому что каждый раз, когда я подключаюсь к этой машине, мой аппаратный адрес кажется одинаковым. Вопрос странный.
user183393
1
Я не сказал, что это был «аппаратный адрес». Я сказал, что это было оборудование из двух частей с одинаковым IP-адресом; в частности, другое оборудование вашего провайдера с тем же IP-адресом, что и у вашего сервера.
MadHatter