1 votes

Étrange problème SSH avec la clé SSH

J'ai un problème étrange avec ssh. J'obtiens un

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

à chaque fois que je me connecte à un serveur. Ensuite, j'ai effacé le fichier known_hosts et je me suis reconnecté. Après 2 à 3 minutes, j'accède à nouveau au serveur et le fichier WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! est encore venu. La connexion ssh s'interrompt automatiquement après la connexion. Je suis sûr que mon IP et mes clés ssh ne changent pas. J'ai vérifié sur le serveur et les clés id_rsa et id_rsa.pub ne changent pas. Mon serveur est également devenu très lent. J'ai également réglé mon serveur contre les attaques de synchronisation et toujours pas de résultat. Quelqu'un peut-il m'aider ?


Le problème existe toujours. La société d'hébergement m'a dit que le réseau n'avait aucun problème. Lorsqu'une connexion ssh est interrompue en raison de ce problème étrange, l'utilisateur n'est pas déconnecté. Quand j'entre dans une nouvelle session en utilisant ssh, je peux voir que l'ancien utilisateur est toujours connecté en tapant la commande W. Si cet utilisateur se déconnecte également et que je me reconnecte, je peux voir que 3 utilisateurs sont connectés, ce qui signifie que les utilisateurs ne sont pas déconnectés.

Voici les logs lorsque la connexion est déconnectée par le serveur

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

2 votes

Je voudrais jamais vider mon known_hosts fichier.

1 votes

Lorsque vous dites que la société d'hébergement vous a dit que " le réseau n'a pas de problème "Que leur avez-vous demandé exactement, qu'ont-ils vérifié, et comment ?

6voto

MadHatter Points 77602

La combinaison de la déconnexion (désynchronisation du flux TCP) et du changement de clés suggère très fortement que vous avez deux appareils avec la même adresse IP. Ce serveur se trouve-t-il sur votre réseau local ou est-il accessible via un routeur ?

Edit : Je soulèverais certainement la question auprès de la société d'hébergement. Il est possible que quelqu'un ait mal compris l'attribution d'une adresse, ou qu'il y ait une faute de frappe dans le formulaire d'inscription. /etc/sysconfig/network-scripts/ifcfg-eth0 (ou un fichier équivalent au système d'exploitation), ou la société d'hébergement s'est plantée. Mais vous ne le saurez pas tant que vous ne leur parlerez pas.

Si le serveur était local, vous pourriez regarder dans votre cache ARP pour voir si l'adresse MAC du serveur change après chaque abandon. Mais comme il est distant, il faudrait qu'il le fasse aussi pour vous.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X