problème ssh

Le
jmdr
j'ai installé Slackware 12.0 sur mon portable inspiron 9300 et j'ai un
problème avec ssh.

Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien.
Mais ssh (ou scp) ne marche pas dans la direction
Autres ordis->portable, alors que ça marche bien dans l'autre sens.

j'utilise le script suivant pour faire marcher le wifi :
iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX
route add 192.168.1.1 dev eth1
route add default gw 192.168.1.1
ifconfig eth0 down

quelqu'un a-t'il une idée pour résoudre ce problème ?

Merci d'avance
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fabien LE LEZ
Le #1895541
On Tue, 10 Jul 2007 17:12:58 +0200, jmdr
Mais ssh (ou scp) ne marche pas dans la direction
Autres ordis---->portable, alors que ça marche bien dans l'autre sens.


Question idiote : est-ce que sshd fonctionne bien sur le portable ?
Que donne un "ssh localhost" ?

jmdr
Le #1895540
Fabien LE LEZ wrote:
On Tue, 10 Jul 2007 17:12:58 +0200, jmdr

Mais ssh (ou scp) ne marche pas dans la direction
Autres ordis---->portable, alors que ça marche bien dans l'autre sens.



Question idiote : est-ce que sshd fonctionne bien sur le portable ?
Que donne un "ssh localhost" ?


Oui ça marche....



Luc.Habert.00__arjf
Le #1895539
Tu essayes de te connecter depuis où, et vers quelle adresse IP? Là, tu es
sur un réseau privé probablement derrière du masquerading, donc sans réglage
spécial sur le routeur, si tu essayes depuis l'extérieur, c'est normal que
ça ne passe pas.
jmdr
Le #1895538
Luc Habert wrote:
Tu essayes de te connecter depuis où, et vers quelle adresse IP? Là, tu es
sur un réseau privé probablement derrière du masquerading, donc sans réglage
spécial sur le routeur, si tu essayes depuis l'extérieur, c'est normal que
ça ne passe pas.



tout se passe bien dans le sens ordis---> extérieur , à partir de
n'importe laquelle des machines installées de mon réseau

ça marche aussi dans le sens portable-->Autres

le seul sens qui ne marche pas c'est d'un autre ordinateur de mon réseau
privé vers le portable.

Fabien LE LEZ
Le #1895536
Que donne un "ssh localhost" ?


Et accessoirement, essaie aussi
ssh 192.168.x.y
(où "192.168.x.y" est l'adresse IP de l'interface wifi du portable)

Pascal Hambourg
Le #1895535
Salut,


Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien.
Mais ssh (ou scp) ne marche pas dans la direction
Autres ordis---->portable, alors que ça marche bien dans l'autre sens.

j'utilise le script suivant pour faire marcher le wifi :
iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX
route add 192.168.1.1 dev eth1
route add default gw 192.168.1.1
ifconfig eth0 down


Un peu foireuse cette configuration réseau. C'est déjà bien beau que ça
cause dans un sens. Et pourquoi cette route d'hôte vers 192.168.1.1 (qui
est le routeur, je suppose) plutôt que vers le réseau 192.168.1.0/24
tout entier ? Je serais intéressé par la sortie d'ifconfig -a et route
-n (ou ip addr et ip route).

quelqu'un a-t'il une idée pour résoudre ce problème ?


A supposer que sshd ne soit pas en cause, soit un problème de config
réseau, soit le firewall local trop restrictif.

Droopy191
Le #1895534
j'ai installé Slackware 12.0 sur mon portable inspiron 9300 et j'ai un
problème avec ssh.

Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien.
Mais ssh (ou scp) ne marche pas dans la direction
Autres ordis---->portable, alors que ça marche bien dans l'autre sens.

j'utilise le script suivant pour faire marcher le wifi :
iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX
route add 192.168.1.1 dev eth1
route add default gw 192.168.1.1
ifconfig eth0 down

quelqu'un a-t'il une idée pour résoudre ce problème ?

Merci d'avance




Salut,

Regarde dans /var/log/authauth.log ( ou variante, connait pas Slackware )
keskidi ?

Ca te permettra de voir si c'est sshd qui refuse la connexion ou que tu
n'atteint meme pas ssh.

--
DR

jmdr
Le #1895532
problème résolu avec :

route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1

Merci pour toutes les réponses
Pascal Hambourg
Le #1895529

problème résolu avec :

route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1


Je m'en doutais. Explication possible :
La machine n'ayant qu'une route directe vers le routeur et pas vers le
sous-réseau local, elle envoie le trafic destiné aux autres machines du
réseau local via le routeur. Celui-ci NATe l'adresse source avant de
faire suivre le paquet vers sa destination finale, comme lors d'une
communication vers internet (cela permet aux redirections NAT de
fonctionner même depuis le réseau local). La destination reçoit le
paquet avec l'adresse source du routeur et y répond. Le routeur reçoit
le paquet, le reconnaît comme une réponse au paquet précédent, remet
l'adresse destination originale et renvoie le paquet à notre machine.
Tout va bien dans ce sens.

Dans l'autre sens, maintenant. Une machine du réseau local veut
communiquer avec notre machine. Elle a normalement une route directe
vers le sous-réseau local, donc elle envoie directement le paquet à la
cible (notre machine). Celle-ci y répond, mais fait transiter le paquet
de réponse par le routeur, comme précédemment, puisqu'elle n'a pas de
route directe vers la destination. Le routeur reçoit le paquet de
réponse *sans avoir vu le paquet initial* et a deux possibilités :
- soit il le considère comme invalide et le rejette ;
- soit il le considère comme une nouvelle connexion, le NATe et le
transfère à sa destination. Problème : le paquet étant NATé, l'adresse
source ne correspond pas à l'adresse de destination du paquet initial,
et la machine ayant émis ce dernier ne le reconnaît pas comme une
réponse.
Bref, dans les deux cas ça ne marche pas. Le grand méchant NAT a encore
frappé !

L'ajout d'une route directe vers le sous-réseau local entier résoud le
problème en évitant que les paquets destinés au réseau local transitent
par le routeur et soient NATés.

Il reste néanmoins un mystère : dans ton script je ne vois pas
d'attribution d'une adresse IP à l'interface wifi eth1. La seule idée
qui me vient est que la machine continue à utiliser l'adresse IP de
l'interface ethernet eth0, bien que cette dernière soit désactivée.
Si une adresse IP avec le masque qui va bien avaient été configurés sur
l'interface wifi, la création de la route directe vers le sous-réseau
aurait été implicite et il n'aurait pas été nécessaire de le faire
manuellement.

jmdr
Le #1895528
Pascal Hambourg wrote:

problème résolu avec :

route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1


Je m'en doutais. Explication possible :
La machine n'ayant qu'une route directe vers le routeur et pas vers le
sous-réseau local, elle envoie le trafic destiné aux autres machines
du réseau local via le routeur. Celui-ci NATe l'adresse source avant
de faire suivre le paquet vers sa destination finale, comme lors d'une
communication vers internet (cela permet aux redirections NAT de
fonctionner même depuis le réseau local). La destination reçoit le
paquet avec l'adresse source du routeur et y répond. Le routeur reçoit
le paquet, le reconnaît comme une réponse au paquet précédent, remet
l'adresse destination originale et renvoie le paquet à notre machine.
Tout va bien dans ce sens.

Dans l'autre sens, maintenant. Une machine du réseau local veut
communiquer avec notre machine. Elle a normalement une route directe
vers le sous-réseau local, donc elle envoie directement le paquet à la
cible (notre machine). Celle-ci y répond, mais fait transiter le
paquet de réponse par le routeur, comme précédemment, puisqu'elle n'a
pas de route directe vers la destination. Le routeur reçoit le paquet
de réponse *sans avoir vu le paquet initial* et a deux possibilités :
- soit il le considère comme invalide et le rejette ;
- soit il le considère comme une nouvelle connexion, le NATe et le
transfère à sa destination. Problème : le paquet étant NATé, l'adresse
source ne correspond pas à l'adresse de destination du paquet initial,
et la machine ayant émis ce dernier ne le reconnaît pas comme une
réponse.
Bref, dans les deux cas ça ne marche pas. Le grand méchant NAT a
encore frappé !

L'ajout d'une route directe vers le sous-réseau local entier résoud le
problème en évitant que les paquets destinés au réseau local
transitent par le routeur et soient NATés.

Il reste néanmoins un mystère : dans ton script je ne vois pas
d'attribution d'une adresse IP à l'interface wifi eth1. La seule idée
qui me vient est que la machine continue à utiliser l'adresse IP de
l'interface ethernet eth0, bien que cette dernière soit désactivée. Si
une adresse IP avec le masque qui va bien avaient été configurés sur
l'interface wifi, la création de la route directe vers le sous-réseau
aurait été implicite et il n'aurait pas été nécessaire de le faire
manuellement.



Bravo ! J'ai un fichier d'initialisation '/etc/rc.d/rc.inet1.conf' qui
contenait ce qui suit :

# Config information for eth0:
IPADDR[0]="192.168.1.105"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""

# Config information for eth1:
IPADDR[1]=""
NETMASK[1]=""
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""



Je l'ai modifié pour remplir IPADDR[1] et NETMASK[1], et maintenant ça
marche sans utiliser l'instruction
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1


Publicité
Poster une réponse
Anonyme