SSH sur IP dynamique

Support Debian
#1

Salut à tous !

J’administre à distance un serveur. Ce serveur a une adresse IP dynamique et je m’y connecte à partir d‘un autre ordinateur pourvu d’une IP dynamique également. Jusqu’à présent, je n’avais pas de problème pour utiliser SSH, mais les IP ont changé et voici le message que j’ai obtenu :

$ ssh XXX@le-bars.net
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
XXXXXXXXXXXXX
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending key in ~/.ssh/known_hosts:7
RSA host key for le-bars.net has changed and you have requested strict checking.
Host key verification failed.

Du coup, je me demande comment faire proprement pour accéder maintenant au serveur et également pour que le problème ne se pose plus à l’avenir – il y a bien la méthode sauvage consistant à supprimer ~/known_hosts, mais je considère que la violence n’est pas une solution.

À bientôt.

Le Farfadet Spatial

#2

C’est ta clef RSA qu’il ne connait pas.
Ça m’est déjà arrivé et il faut faire reconnaître à nouveau sa clef.
Malheureeusement, je ne me souviens plus de la commande pour ce faire.
Par contre, en dépannage, je peux t’indiquer une méthode un peu crade :
Tu vas dans
~/.ssh/known_hosts
et tu commentes les lignes existantes, ou alors tu modifies le fichier en .old pour en garder une trace, au cas où et tu recrée un fichier “known_hosts” vierge.
Ensuite, tu retentes un “ssh” et il te demandera confirmation puis inscrira la nouvelle clef.

#3

Bonjour,

Édite ton ~/.ssh/known_hosts, commente/supprime la ligne numéro 7.
Puis :

A+

#4

J’ai le même problème en local :
J’ai beau donné des ip fixes en local à mes machines ma bbox bugue et à chaque redémarrage elle efface tout, donc ssh voit que la clé n’est plus attribuée à la même IP et considère ceci comme une attaque possible… Il suffit en effet de recréer un nouveau fichier /home/user/.ssh/known_hosts (en sauvegardant l’ancien ou pas).
Tu peux aussi si c’est une machine distante créer un compte chez dyndns.org…

#5

Re,

Edit : @ ricardo,
Je viens de voir que tu as supprimé ton message que j’avais quoté, je supprime aussi mon quote. :wink:

En affichant les numéros de ligne ?

Ou :

~/.ssh$ cat -b known_hosts 1 |1| 2 |1| 3 |1| 4 |1| 5 |1| 6 |1| 7 |1|

A+

#6

Oui, parce que j’avais tapé trop vite en oubliant qu’on pouvait numéroter les lignes.
Cela dit, c’est en gros, ce que je préconisais, mais en plus précis.

EDIT :
Mais je crois qu’il existe une méthode moins “crade”, que j’ai oubliée, malheureusement, qui restaure la bonne clef.

#7

Re,

[quote=“ricardo”]EDIT :
Mais je crois qu’il existe une méthode moins “crade”, que j’ai oubliée, malheureusement, qui restaure la bonne clef.[/quote]
En recopiant la clé sur le serveur ?

Sinon, je ne vois pas.

[i]Edit :
Il y a aussi mais je n’ai pas essayé :

[/i]

A+

#8

Salut à tous !

Déjà, je vous remercie de vous intéresser à mon problème.

Cela dit, comme je le laissais entendre dans mon premier message (quoique sans doute pas assez clairement), j’ai déjà pensé aux solutions que vous donnez, mais je ne les trouve pas très propres. Si, décidément, il n’y a pas de meilleure solution, je vais m’y résoudre, mais je voudrais d’abord m’assurer qu’il n’existe pas une méthode moins brutale.

À bientôt.

Le Farfadet Spatial

#9

Salut,
Comme suggéré, la méthode la plus propre, c’est celle-ci: isalo.org/wiki.debian-fr/ind … ourcis_ssh

Un fois la clef serveur copiée chez le client, tu ne devrais plus avoir de soucis.
Et puis avec un fichier de config dans ~/.ssh tu aura une commande plus simple à taper…

ssh labas :wink:

La méthode “sauvage” est obligatoire pour enlever l’avertissement.

#10

De mémoire je crois que ce qui suit marche: Ton problème est que ta machine a le même nom mais une IP qui change, édite le fichier ~/.ssh/known_hosts, la fameuse ligen 7 ressemble à

remplace ça par

de cette façon ça devrait passer. (Sans garantie)

#11

[quote=“fran.b”]De mémoire je crois que ce qui suit marche: Ton problème est que ta machine a le même nom mais une IP qui change, édite le fichier ~/.ssh/known_hosts, la fameuse ligen 7 ressemble à

remplace ça par

de cette façon ça devrait passer. (Sans garantie)[/quote]
Bizarre ta proposition François !
Les clef sont des suites de signes sans espaces et tu proposes un début avec des espaces ???

#12

Son problème est que la clef du serveur n’est pas en accord avec celle stockée dans .known_hosts. Le format de ce fichier est une série de lignes de 3 champs séparés par des espaces:

1er champ: nom ou IP ou nom et IP de la machine, en clair ou chiffrée (hachée plutôt) via une empreinte (hachage) type md5sum (dans ce cas, ça commence par |1| ou un autre chiffre en fonction du type de hachage retenu. C’est ce champ qu’il faut modifier afin que la clef soit associée au nom seul et pas au nom + IP.
2ième champ: type de clef (ssh-rsa ou ssh-dsa essentiellement)
3ième champ: la clef publique

#13

En effet, au temps pour moi, j’étais persuadé que tout se touchait. J’ai vérifié sur mes clefs, et, en effet, il y a bien deux “trous”.
Donc ton raisonnement se tient :006

#14

Salut à tous !

La méthode me semblait intéressante et le raisonnement se tenait. J’ai donc changé uniquement le premier champ pour y indiquer « le-bars.net », mais la connexion a été tout de même refusée. J’ai également tenté de mettre « le-bars.net= », mais ça n’a pas été plus probant (quoique cette fois-ci le mot de passe m’a été demandé). Est-ce que cela semble une bonne idée de réaliser un hashage MD5 sur la chaîne « le-bars.net » ?

À bientôt.

Le Farfadet Spatial

#15

Hum, je suis déçu, il me semble que j’utilisais cela lorsque je travaillais sur des IPs dynamiques. Je ne crois pas que de le hacher change quelque chose.

#16

Salut à tous !

Bon, il semble bien que finalement ta solution fonctionne et que j’ai un problème de plus. Pour l’instant, je n’ouvre pas de nouveau sujet, mais s’il s’avère que le sujet dévie trop, j’en ferais un autre.

Donc, j’ai remplacé le premier champ par « le-bars.net= ». Voici alors ce que j’obtiens :

$ ssh XXX@le-bars.net
The authenticity of host 'le-bars.net (85.170.106.220)' can't be established.
RSA key fingerprint is XXXXXX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'le-bars.net' (RSA) to the list of known hosts.
Warning: the RSA host key for 'le-bars.net' differs from the key for the IP address '85.170.106.220'
Offending key for IP in /home/farfadet/.ssh/known_hosts:14
Are you sure you want to continue connecting (yes/no)? yes
DD-WRT v24-sp2 vpn (c) 2010 NewMedia-NET GmbH
Release: 08/07/10 (SVN revision: 14896)
XXX@le-bars.net's password: 
Permission denied, please try again.
XXX@le-bars.net's password: 
Permission denied, please try again.
XXX@le-bars.net's password: 
Permission denied (publickey,password).

J’ai essayé plusieurs fois, l’accès m’est toujours refusé et je ne pense pas faire d’erreur sur le mot de passe. Là, je sèche : est-ce que quelqu’un a une idée pour déjà essayer de savoir ce qui se passe ?

À bientôt.

Le Farfadet Spatial

#17

Salut à tous !

J’ai supprimé la ligne 14, ce qui corrige déjà une partie du problème, mais l’accès m’est toujours refusé :

$ ssh yXXX@le-bars.net
DD-WRT v24-sp2 vpn (c) 2010 NewMedia-NET GmbH
Release: 08/07/10 (SVN revision: 14896)
XXX@le-bars.net's password: 
Permission denied, please try again.
XXX@le-bars.net's password: 
Permission denied, please try again.
XXX@le-bars.net's password: 
Permission denied (publickey,password).

Ça donne clairement l’impression que soit le mot de passe, soit le nom d’utilisateur (voire les deux) est refusé. Bon sang ! J’ai pourtant réussi à me connecter au serveur auparavant.

Je vais voir si ce n’est pas un problème avec le DNS qui serait mal configuré.

À bientôt.

Le Farfadet Spatial

#18

Hum, que donne les logs sur le serveur (/var/log/auth.log)

#19

Je sais qu’en principe, ssh se pratique en ‘user’ mais as-tu essayé quand même en tant que ‘root’ ?

#20

Salut à tous !

Je pense que tu parles de ceux du serveur lui-même, c’est-à-dire à la machine à laquelle je n’ai pas d’accès physique (un océan nous sépare). Le problème, c’est que tant que je ne peux pas me connecter à la machine, je ne peux pas le savoir…

J’ai supprimé le mot de passe de root – oui, c’est la même approche que sous Ubuntu, je trouve que sur ce point c’est élégant. Du coup, je ne peux pas me connecter en tant que root, mais c’est normal.

Le serveur est chez ma sœur et je lui ai créé un compte à qui j’ai donné les droits d’administration grâce à Sudo (il y a donc deux comptes administrateurs sur ce serveur). Je vais déjà vérifier l’adresse IP, ensuite on verra si j’ai plus de chance par ce canal.

À bientôt.

Le Farfadet Spatial