Ssh & connexion refusée

Support Debian
#1

Salut,

[quote]gerard@debian:~$ aptitude search openssh | grep ^i
i openssh-blacklist - list of default blacklisted OpenSSH RSA an
i openssh-client - secure shell (SSH) client, for secure acce
i openssh-server - secure shell (SSH) server, for secure acce
gerard@debian:~$
[/quote]

[quote]gerard@debian:~$ ssh glu
ssh: connect to host glu port 22: Connection refused
[/quote]

La situation : Deux ordinateurs reliés par un routeur.
Le premier comporte deux Debian sans autre point commun que la swap.
A - une 686 ==> "syno"
B - une amd64 ==> “glu”

Le routeur ne connaît qu’une seule connexion “glu” 192.168.0.2 puisqu’il ne connaît qu’une seule carte réseau.

Depuis le second ordinateur la connexion ssh vers le 686 fonctionne avec ssh glu ?
Depuis ce même ordinateur la connexion ssh répond :

Bien évidemment “syno” et “glu” ne peuvent être actifs en même temps, il s’agit d’installation en dur et non de VM !

Où est mon erreur ?

#2

Ce n’est pas une question de clefs RSA :stuck_out_tongue:

EDIT : regarde du côté de ~/.ssh/known_hosts
Commente ttes les lignes qui commencent par [1]
et recommence ton essai

#3

La commande ping glu
affiche-t-elle la même IP selon qu’elle soit lancé sur un ordinateur ou l’autre ?
Si ce n’est pas le cas, il faut probablement corriger ton fichier /etc/hosts

Aurais-tu une règle de pare-feu qui bloque ?
SSH écoute-t-il bien sur toutes les interfaces, y compris lo ?

# iptables-save
# netstat -lpn | grep 22
#4

salut,

1 - C’est le routeur qui attribue l’IP en fonction du MAC
2 - C’est le routeur qui sert de parefeu à tout le réseau

#5

Et l’acces par user/IP dans tout ça, il raconte quoi ?

#6

Salut,

A force de trifouiller j’ai réussi à faire disparaître le phénomène.

1 - Effacé sur les deux machines les fichiers authorized & known
2 - Refaire les ssh-copy-id de gerard et root

3 - Tout fonctionne mais j’aime pas ne pas savoir quelle bétise j’avais faite précédemment :mrgreen:

#7

Hello.

il y a plusieurs bugs en cours sur le paquet openssh-client >= 1:5.8p1-2 :
#612607: Connecting to older ssh version has cipher negotiation problem
#613505: ssh client fails to login to any ssh server (“reset by peer”)
#613649: openssh-client: After upgrading to 1:5.8p1-2 ssh fails to connect to some servers

La version 1:5.5p1-6 de testing fonctionne bien.

@+…

#8

Salut et merci,

Après tout ce n’est peut-être pas moi qui ai fait une boulette. Cela m’étonnait aussi :laughing: :laughing: :laughing:

#9

Tu n 'avais pas fait de bêtise, c’est tout simplement que ta clef RSA a été donnée pour une machine ET une distrib.
Quand tu changes de distrib, Mr SSH se base toujours sur la même machine car MAC ne change pas. seulement, le reste de la clef ne concorde plus, donc, “y veut pas”.
Fais l’essai de revenir à ta première distrib, en ne touchant pas aux clefs, et tu verras qu’il bronchera de nouveau.

#10

Re,

Non, Ricardo, sous aptosid on change de release au moins une fois par semaine et c’est la première fois en plus de deux ans que cette erreur se produit !
Mais par contre je veux bien croire au bug dans ssh (apt-listbugs me l’avait signalé mais j’ai voulu jouer au malin) :041

#11

[quote=“ggoodluck47”]Salut,

A force de trifouiller j’ai réussi à faire disparaître le phénomène.

1 - Effacé sur les deux machines les fichiers authorized & known
2 - Refaire les ssh-copy-id de gerard et root

3 - Tout fonctionne mais j’aime pas ne pas savoir quelle bétise j’avais faite précédemment :mrgreen:[/quote]
Tout cela me fait penser à un problème de droit sur l’un des fichiers (ou sur les 2)
C’est une cause fréquente
(tout comme sur le dossier .ssh et/ou sur le home de l’utilisateur)