Probleme ssh

Support Debian
#1

Bonjour à tous,

Voici mon problème:

Je dois créer une connexion sftp depuis une debian squeeze vers un serveur.
plusieurs connexion vers d’autres serveurs fonctionnent très bien
mais pour une raison que je ne m’explique pas, je n’arrive pas à me connecter à celui-ci:

acidenitrix:~# ssh -vvv user@IPDUSERVEUR OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to IPDUSERVEUR [IPDUSERVEUR] port 22.

puis timeout au bout de quelques minutes.

j’ai essayé depuis une autre debian qui est sur le même reseau et là tout fonctionne correctement.

Si quelqu’un à une idée, je suis preneur.

merci

#2

Quel est le message d’erreur exact ?

#3

C’est justement là le problème,

il ne semble pas y avoir d’erreurs, le programme reste deux minutes le dessus :

debug1: Connecting to IPDUSERVEUR [IPDUSERVEUR] port 22.

j’imagine qu’il tente tant qu’il n’y arrive pas et arrete sur un timeout

je reprecise que ce poste se connecte parfaitement sur d’autres serveurs

#4

Parefeu ?
Fail2ban ?
Jeu de clefs ?
Config SSH : l’utilisateur de cette machine qui va pas est bien présent ?

#5

Parefeu: non, je me connecte à ce serveur depuis un autre poste

fail2ban: je ne sais pas trop ce que c’est, je vais regarder.
mais du peu que j’en ai lu, il s’agit d’un système qui stoppe les IP entrantes qui ont précédemment trop tenté de connexions.
Or mes deux machines locales sortent par la même IP donc ce syteme devrait les bloquer toutes les deux (si j’ai bien compris)

jeu de clefs: non pas de clés, le client veut que je me connecte chez lui avec mot de passe

de quelle machine parles tu?
locale oui
distante aussi, je m’y connecte depuis un autre poste

#6

[quote=“pislastdecimal”]l ne semble pas y avoir d’erreurs, le programme reste deux minutes le dessus :
debug1: Connecting to IPDUSERVEUR [IPDUSERVEUR] port 22.[/quote]
Et ensuite ? Il quitte sans aucun message ?

N’imagine pas ; vérifie plutôt avec une capture de paquets.[quote=“pislastdecimal”]Parefeu: non, je me connecte à ce serveur depuis un autre poste[/quote]
Pas de pare-feu sur ce poste ?

#7

ensuite il quite avec:

ssh: connect to host ip port 22: Connection timed out

le parefeu n’est pas sur le poste, il est plus près du wan

un netstat me donne ça:

Je rajouterai que sans avoir rien fait, modifié ou reloadé … ça fonctionne …
Je n’y comprends rien.

Si je trouve pourquoi ça fonctionne d’un coup, je mettrai une explication
Merci d’avoir pris le temps de m’aider

#8

SYN_SENT indique l’absence de réponse du serveur à la demande de connexion TCP (SYN) du client. 2 minutes, ça ma paraît un peu long pour ce genre de time-out. Sur ma machine c’est plutôt de l’ordre de 30 secondes.
Quand ça se produit tu peux lancer un tcptraceroute sur le port 22 du serveur pour essayer de voir où ça coince.

#9

merci, je ne connaissais pas cette commande.

je viens de tester sur une autre machine pour laquelle la connexion ne s’établit pas,
et rien ne se passe:

tcptraceroute x.x.x.x 22 Selected device eth2, address 192.168.0.12, port 33427 for outgoing packets Tracing the path to x.x.x.x on TCP port 22 (ssh), 30 hops max 1 192.168.2.254 1.506 ms 1.652 ms 1.232 ms 2 * * * 3 * * * ... 12 * * * 13 * * * 14 * * * 15 * * * ...

#10

regarde voir du coté des logs fail2ban si tu as pas eté blacklisté

#11

Si je comprends bien il n’y a pas qu’une machine qui a ce genre de problème ?
D’après le tcptraceroute, le blocage se situe sur ou juste après le premier routeur (192.168.2.254). Tu as comparé avec le résultat depuis une machine qui n’a pas le problème ?

#12

[quote]Si je comprends bien il n’y a pas qu’une machine qui a ce genre de problème ?
D’après le tcptraceroute, le blocage se situe sur ou juste après le premier routeur (192.168.2.254). Tu as comparé avec le résultat depuis une machine qui n’a pas le problème ?[/quote]
exact ! (ce routeur est le firewall)

le responsable réseau vient de me dire qu’il avait des natages/routages en doublons pour certaines IP locales
qui pourraient éventuellement créer des conflits. (n’y connaissant rien, je le crois sur parole.)
Comme il ne m’avait pas avertit qu’il en en avait desactivé une ou deux, j’ai été surpris de voir que tout refonctionnait d’un coup!

ce que je ne m’explique pas, c’est pourquoi cette machine arrivait à sortir du local en ssh pour d’autres ip…

merci d’avoir pris le temps de m’aider pour un faux problème