Je souhaiterais accéder à ma machine à la maison via ssh depuis
l'extérieur. La configuration de ssh fonctionne depuis le réseau
domestique.
Il me reste donc à configurer mon routeur pour que la machine soit
accessible de partout. Sur la Neufbox, j'ai donc ouvert le port 22 (TCP
et UDP) , qui est redirigé vers l'IP 192.168.1.20 qui est celle de mon
PC, sur le port 22 lui aussi.
Je voulais savoir si cette manipulation est correcte. En effet, lorsque
je teste la connexion avec l'IP de la box depuis le réseau interne, ça
ne fonctionne pas, et je n'ai pas sous la main un réseau indépendant
pour tester si ça fonctionne depuis l'exterieur. Je verrai demain.
Question : est-il possible/normal que ça marche différemment depuis le
réseau privé ? Et sinon, que faut-il faire ?
Le Mon, 11 Aug 2008 15:58:02 +0200, JOORIS Emmanuel a écrit dans le message :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a son ip publique depuis le réseau interne. si vous voulez envoyer moi votre ip par message privé et je pourrai essayer de me connecter a votre réseau (je me limiterai uniquement a ceci).
Ce sera le comportement sur tous les routeurs, le NAT est un concept qui raisonne par interface (interne / externe).
Dans ce genre de situation, il convient d'utiliser l'adresse interne quand on est à l'intérieur, par exemple en renseignant un fichier 'hosts' en interne, ou avec une vue sur le serveur DNS dans un réseau plus grand.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...] Escape character is '^]'. SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
-- Raphael Bouaziz.
Le Mon, 11 Aug 2008 15:58:02 +0200, JOORIS Emmanuel a écrit
dans le message <1218463082.23447.2.camel@localhost> :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a
son ip publique depuis le réseau interne. si vous voulez envoyer moi
votre ip par message privé et je pourrai essayer de me connecter a votre
réseau (je me limiterai uniquement a ceci).
Ce sera le comportement sur tous les routeurs, le NAT est
un concept qui raisonne par interface (interne / externe).
Dans ce genre de situation, il convient d'utiliser l'adresse interne
quand on est à l'intérieur, par exemple en renseignant un fichier
'hosts' en interne, ou avec une vue sur le serveur DNS dans un
réseau plus grand.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...]
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
Le Mon, 11 Aug 2008 15:58:02 +0200, JOORIS Emmanuel a écrit dans le message :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a son ip publique depuis le réseau interne. si vous voulez envoyer moi votre ip par message privé et je pourrai essayer de me connecter a votre réseau (je me limiterai uniquement a ceci).
Ce sera le comportement sur tous les routeurs, le NAT est un concept qui raisonne par interface (interne / externe).
Dans ce genre de situation, il convient d'utiliser l'adresse interne quand on est à l'intérieur, par exemple en renseignant un fichier 'hosts' en interne, ou avec une vue sur le serveur DNS dans un réseau plus grand.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...] Escape character is '^]'. SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
-- Raphael Bouaziz.
Raphael Bouaziz
Le Mon, 11 Aug 2008 15:58:02 +0200, JOORIS Emmanuel a écrit dans le message :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a son ip publique depuis le réseau interne. si vous voulez envoyer moi votre ip par message privé et je pourrai essayer de me connecter a votre réseau (je me limiterai uniquement a ceci).
Ce sera le comportement sur tous les routeurs, sauf si règles ou implémentation spécifique destinées à contourner explicitement ce "problème". De base, le NAT est un concept qui raisonne par interface (interne / externe).
Dans ce genre de situation, il convient d'utiliser l'adresse interne quand on est à l'intérieur, par exemple en renseignant un fichier 'hosts' en interne, ou avec une vue sur le serveur DNS dans un réseau plus grand.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...] Escape character is '^]'. SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
-- Raphael Bouaziz.
Le Mon, 11 Aug 2008 15:58:02 +0200, JOORIS Emmanuel a écrit
dans le message <1218463082.23447.2.camel@localhost> :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a
son ip publique depuis le réseau interne. si vous voulez envoyer moi
votre ip par message privé et je pourrai essayer de me connecter a votre
réseau (je me limiterai uniquement a ceci).
Ce sera le comportement sur tous les routeurs, sauf si règles
ou implémentation spécifique destinées à contourner explicitement
ce "problème". De base, le NAT est un concept qui raisonne par
interface (interne / externe).
Dans ce genre de situation, il convient d'utiliser l'adresse interne
quand on est à l'intérieur, par exemple en renseignant un fichier
'hosts' en interne, ou avec une vue sur le serveur DNS dans un
réseau plus grand.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...]
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
Le Mon, 11 Aug 2008 15:58:02 +0200, JOORIS Emmanuel a écrit dans le message :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a son ip publique depuis le réseau interne. si vous voulez envoyer moi votre ip par message privé et je pourrai essayer de me connecter a votre réseau (je me limiterai uniquement a ceci).
Ce sera le comportement sur tous les routeurs, sauf si règles ou implémentation spécifique destinées à contourner explicitement ce "problème". De base, le NAT est un concept qui raisonne par interface (interne / externe).
Dans ce genre de situation, il convient d'utiliser l'adresse interne quand on est à l'intérieur, par exemple en renseignant un fichier 'hosts' en interne, ou avec une vue sur le serveur DNS dans un réseau plus grand.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...] Escape character is '^]'. SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
-- Raphael Bouaziz.
olive
JOORIS Emmanuel écrivait :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a son ip publique depuis le réseau interne.
Je l'ignorais. Voyez-vous une raison technique à celà ?
si vous voulez envoyer moi votre ip par message privé et je pourrai essayer de me connecter a votre réseau (je me limiterai uniquement a ceci).
Je vous remercie pour votre proposition ; un autre contributeur a fait le test à partir de l'IP de mes en-têtes et ça semble fonctionner.
-- Olivier
JOORIS Emmanuel écrivait :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a
son ip publique depuis le réseau interne.
Je l'ignorais. Voyez-vous une raison technique à celà ?
si vous voulez envoyer moi votre ip par message privé et je pourrai
essayer de me connecter a votre réseau (je me limiterai uniquement a
ceci).
Je vous remercie pour votre proposition ; un autre contributeur a fait
le test à partir de l'IP de mes en-têtes et ça semble fonctionner.
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a son ip publique depuis le réseau interne.
Je l'ignorais. Voyez-vous une raison technique à celà ?
si vous voulez envoyer moi votre ip par message privé et je pourrai essayer de me connecter a votre réseau (je me limiterai uniquement a ceci).
Je vous remercie pour votre proposition ; un autre contributeur a fait le test à partir de l'IP de mes en-têtes et ça semble fonctionner.
-- Olivier
olive
Raphael Bouaziz ecrivait :
Ce sera le comportement sur tous les routeurs, sauf si règles ou implémentation spécifique destinées à contourner explicitement ce "problème". De base, le NAT est un concept qui raisonne par interface (interne / externe).
D'accord. Il est donc difficile de simuler le comportement d'une connexion externe si on est sur le réseau domestique.
Dans ce genre de situation, il convient d'utiliser l'adresse interne quand on est à l'intérieur, par exemple en renseignant un fichier 'hosts' en interne, ou avec une vue sur le serveur DNS dans un réseau plus grand.
Bien.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...] Escape character is '^]'. SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
Je vous remercie pour votre attention.
L'identification se fait par login/password (non-basiques), je n'ai pas encore pris la peine de me pencher sur la question du chiffrage par clef. Cela vous semble-t-il poser un problème de sécurité pour une machine d'un particulier ?
-- Oliiver
Raphael Bouaziz ecrivait :
Ce sera le comportement sur tous les routeurs, sauf si règles
ou implémentation spécifique destinées à contourner explicitement
ce "problème". De base, le NAT est un concept qui raisonne par
interface (interne / externe).
D'accord. Il est donc difficile de simuler le comportement d'une
connexion externe si on est sur le réseau domestique.
Dans ce genre de situation, il convient d'utiliser l'adresse interne
quand on est à l'intérieur, par exemple en renseignant un fichier
'hosts' en interne, ou avec une vue sur le serveur DNS dans un
réseau plus grand.
Bien.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...]
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
Je vous remercie pour votre attention.
L'identification se fait par login/password (non-basiques), je n'ai pas
encore pris la peine de me pencher sur la question du chiffrage par clef.
Cela vous semble-t-il poser un problème de sécurité pour une machine
d'un particulier ?
Ce sera le comportement sur tous les routeurs, sauf si règles ou implémentation spécifique destinées à contourner explicitement ce "problème". De base, le NAT est un concept qui raisonne par interface (interne / externe).
D'accord. Il est donc difficile de simuler le comportement d'une connexion externe si on est sur le réseau domestique.
Dans ce genre de situation, il convient d'utiliser l'adresse interne quand on est à l'intérieur, par exemple en renseignant un fichier 'hosts' en interne, ou avec une vue sur le serveur DNS dans un réseau plus grand.
Bien.
En attendant depuis l'extérieur ça a l'air de fonctionner :
[...] Escape character is '^]'. SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1.4
La connexion est arrivée depuis 62.4.17.169 (pour info).
Je vous remercie pour votre attention.
L'identification se fait par login/password (non-basiques), je n'ai pas encore pris la peine de me pencher sur la question du chiffrage par clef. Cela vous semble-t-il poser un problème de sécurité pour une machine d'un particulier ?
-- Oliiver
Pascal Hambourg
Salut,
olive a écrit :
JOORIS Emmanuel écrivait :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a son ip publique depuis le réseau interne.
Je l'ignorais. Voyez-vous une raison technique à celà ?
Ce n'est tout simplement pas prévu dans la conception du routeur. Le bidule est prévu pour traiter la redirection depuis l'extérieur, or une redirection depuis le réseau interne ne se déroule pas de la même façon.
Lorsque la demande de connexion vient de l'extérieur, elle arrive sur l'interface externe, le routeur modifie l'adresse destination et la transmet au serveur sur le réseau internet. Lorsque le serveur envoie la réponse, il utilise la route par défaut via le routeur puisque le client est hors du réseau interne. La réponse arrive sur l'interface interne du routeur qui remet l'adresse originale et la transmet via son interface externe au client pour qui tout ceci est invisible.
Lorsque la demande de connexion vient de l'intérieur, déjà elle arrive sur l'interface interne du routeur. Admettons que celui-ci ne fasse pas de différence et modifie l'adresse destination de la même façon. Il doit ensuite retransmettre le paquet au serveur par la même interface que par où il l'a reçue, contrairement au cas précédent. Admettons qu'il le fasse. Quand le serveur répond, il voit que l'adresse client est dans le même réseau que lui, donc il lui envoie la réponse directement sans utiliser la route par défaut via le routeur. Mais le client reçoit la réponse avec l'adresse du serveur alors qu'il avait envoyé une requête à l'adresse du routeur. La connexion échoue. Pour qu'elle fonctionne, il faut en plus que le routeur modifie l'adresse source du paquet, pour que le serveur croie qu'il vient du routeur et lui envoie la réponse comme dans le premier cas.
Salut,
olive a écrit :
JOORIS Emmanuel écrivait :
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a
son ip publique depuis le réseau interne.
Je l'ignorais. Voyez-vous une raison technique à celà ?
Ce n'est tout simplement pas prévu dans la conception du routeur. Le
bidule est prévu pour traiter la redirection depuis l'extérieur, or une
redirection depuis le réseau interne ne se déroule pas de la même façon.
Lorsque la demande de connexion vient de l'extérieur, elle arrive sur
l'interface externe, le routeur modifie l'adresse destination et la
transmet au serveur sur le réseau internet. Lorsque le serveur envoie la
réponse, il utilise la route par défaut via le routeur puisque le client
est hors du réseau interne. La réponse arrive sur l'interface interne du
routeur qui remet l'adresse originale et la transmet via son interface
externe au client pour qui tout ceci est invisible.
Lorsque la demande de connexion vient de l'intérieur, déjà elle arrive
sur l'interface interne du routeur. Admettons que celui-ci ne fasse pas
de différence et modifie l'adresse destination de la même façon. Il doit
ensuite retransmettre le paquet au serveur par la même interface que par
où il l'a reçue, contrairement au cas précédent. Admettons qu'il le
fasse. Quand le serveur répond, il voit que l'adresse client est dans le
même réseau que lui, donc il lui envoie la réponse directement sans
utiliser la route par défaut via le routeur. Mais le client reçoit la
réponse avec l'adresse du serveur alors qu'il avait envoyé une requête à
l'adresse du routeur. La connexion échoue. Pour qu'elle fonctionne, il
faut en plus que le routeur modifie l'adresse source du paquet, pour que
le serveur croie qu'il vient du routeur et lui envoie la réponse comme
dans le premier cas.
Ce genre de modem routeur réagit très mal quand on essaye d'accéder a son ip publique depuis le réseau interne.
Je l'ignorais. Voyez-vous une raison technique à celà ?
Ce n'est tout simplement pas prévu dans la conception du routeur. Le bidule est prévu pour traiter la redirection depuis l'extérieur, or une redirection depuis le réseau interne ne se déroule pas de la même façon.
Lorsque la demande de connexion vient de l'extérieur, elle arrive sur l'interface externe, le routeur modifie l'adresse destination et la transmet au serveur sur le réseau internet. Lorsque le serveur envoie la réponse, il utilise la route par défaut via le routeur puisque le client est hors du réseau interne. La réponse arrive sur l'interface interne du routeur qui remet l'adresse originale et la transmet via son interface externe au client pour qui tout ceci est invisible.
Lorsque la demande de connexion vient de l'intérieur, déjà elle arrive sur l'interface interne du routeur. Admettons que celui-ci ne fasse pas de différence et modifie l'adresse destination de la même façon. Il doit ensuite retransmettre le paquet au serveur par la même interface que par où il l'a reçue, contrairement au cas précédent. Admettons qu'il le fasse. Quand le serveur répond, il voit que l'adresse client est dans le même réseau que lui, donc il lui envoie la réponse directement sans utiliser la route par défaut via le routeur. Mais le client reçoit la réponse avec l'adresse du serveur alors qu'il avait envoyé une requête à l'adresse du routeur. La connexion échoue. Pour qu'elle fonctionne, il faut en plus que le routeur modifie l'adresse source du paquet, pour que le serveur croie qu'il vient du routeur et lui envoie la réponse comme dans le premier cas.
olive
Pascal Hambourg ecrivait :
(snip l'explication détaillée)
Merci beaucoup pour ces précisions, ainsi qu'à l'ensemble des intervenants de ce fil ; j'ai appris des choses.
Pour information : la connexion fonctionne bien depuis l'extérieur, comme vous le laissiez entendre.
-- Olivier
Pascal Hambourg ecrivait :
(snip l'explication détaillée)
Merci beaucoup pour ces précisions, ainsi qu'à l'ensemble des
intervenants de ce fil ; j'ai appris des choses.
Pour information : la connexion fonctionne bien depuis l'extérieur,
comme vous le laissiez entendre.
Merci beaucoup pour ces précisions, ainsi qu'à l'ensemble des intervenants de ce fil ; j'ai appris des choses.
Pour information : la connexion fonctionne bien depuis l'extérieur, comme vous le laissiez entendre.
-- Olivier
JB
olive a écrit :
L'identification se fait par login/password (non-basiques), je n'ai pas encore pris la peine de me pencher sur la question du chiffrage par clef. Cela vous semble-t-il poser un problème de sécurité pour une machine d'un particulier ?
Déja vous pouvez changer le port de SSH, ca evite au moins 99% des scans.
Ensuite, un bon mot de passe fera très bien l'affaire
Si vous etes un peu parano, interdisez le login de root (dans ssh config) et créez vous un autre utilisateur depuis lequel vous pourrez ensuite vous 'su'
cdlt
ju
olive a écrit :
L'identification se fait par login/password (non-basiques), je n'ai pas
encore pris la peine de me pencher sur la question du chiffrage par clef.
Cela vous semble-t-il poser un problème de sécurité pour une machine
d'un particulier ?
Déja vous pouvez changer le port de SSH, ca evite au moins 99% des scans.
Ensuite, un bon mot de passe fera très bien l'affaire
Si vous etes un peu parano, interdisez le login de root (dans ssh
config) et créez vous un autre utilisateur depuis lequel vous pourrez
ensuite vous 'su'
L'identification se fait par login/password (non-basiques), je n'ai pas encore pris la peine de me pencher sur la question du chiffrage par clef. Cela vous semble-t-il poser un problème de sécurité pour une machine d'un particulier ?
Déja vous pouvez changer le port de SSH, ca evite au moins 99% des scans.
Ensuite, un bon mot de passe fera très bien l'affaire
Si vous etes un peu parano, interdisez le login de root (dans ssh config) et créez vous un autre utilisateur depuis lequel vous pourrez ensuite vous 'su'
cdlt
ju
Mateusz Viste
В Понедельник 11 августа 2008 16:32, olive писал:
L'identification se fait par login/password (non-basiques), je n'ai pas encore pris la peine de me pencher sur la question du chiffrage par clef. Cela vous semble-t-il poser un problème de sécurité pour une machine d'un particulier ?
Bonjour,
Personnellement, jamais je ne laisserais un accès ssh tourner publiquement en login/mot de passe... Si la ou les adresses des IP distantes sont connues, il serait bien plus raisonnable de mettre en place un filtrage par IP source. Sinon, si cet accès doit effectivement être public, je bloque généralement l'accès par mot de passe, et rajoute ma clef public dans /.ssh (clef RSA ou DSS au choix). Les chances de casser une telle clef (dans un temps raisonnable) sont quasi nuls. S'il s'agit du changement de port, je n'y crois pas trop. L'obfuscation n'est qu'apparente...
Cordialement, Mateusz VISTE
В Понедельник 11 августа 2008 16:32, olive писал:
L'identification se fait par login/password (non-basiques), je n'ai pas
encore pris la peine de me pencher sur la question du chiffrage par clef.
Cela vous semble-t-il poser un problème de sécurité pour une machine
d'un particulier ?
Bonjour,
Personnellement, jamais je ne laisserais un accès ssh tourner publiquement
en login/mot de passe...
Si la ou les adresses des IP distantes sont connues, il serait bien plus
raisonnable de mettre en place un filtrage par IP source.
Sinon, si cet accès doit effectivement être public, je bloque généralement
l'accès par mot de passe, et rajoute ma clef public dans /.ssh (clef RSA ou
DSS au choix). Les chances de casser une telle clef (dans un temps
raisonnable) sont quasi nuls. S'il s'agit du changement de port, je n'y
crois pas trop. L'obfuscation n'est qu'apparente...
L'identification se fait par login/password (non-basiques), je n'ai pas encore pris la peine de me pencher sur la question du chiffrage par clef. Cela vous semble-t-il poser un problème de sécurité pour une machine d'un particulier ?
Bonjour,
Personnellement, jamais je ne laisserais un accès ssh tourner publiquement en login/mot de passe... Si la ou les adresses des IP distantes sont connues, il serait bien plus raisonnable de mettre en place un filtrage par IP source. Sinon, si cet accès doit effectivement être public, je bloque généralement l'accès par mot de passe, et rajoute ma clef public dans /.ssh (clef RSA ou DSS au choix). Les chances de casser une telle clef (dans un temps raisonnable) sont quasi nuls. S'il s'agit du changement de port, je n'y crois pas trop. L'obfuscation n'est qu'apparente...
