[débutant] configuration d'une box pour ssh

Le
olive
Bonjour,

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 ?

Je vous remercie.

--
Olivier
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JOORIS Emmanuel
Le #16524421
Le lundi 11 août 2008 à 15:52 +0200, olive a écrit :
Bonjour,

Je souhaiterais accéder à ma machine à la maison via ssh d epuis
l'extérieur. La configuration de ssh fonctionne depuis le résea u
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 m on
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épe ndant
pour tester si ça fonctionne depuis l'exterieur. Je verrai demain.

Question : est-il possible/normal que ça marche différemment de puis le
réseau privé ? Et sinon, que faut-il faire ?

Je vous remercie.




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 vot re
réseau (je me limiterai uniquement a ceci).
Raphael Bouaziz
Le #16524411
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 #16524401
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
Le #16524591
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
olive
Le #16524691
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
Pascal Hambourg
Le #16527721
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.
olive
Le #16533611
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
JB
Le #16596081
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
Mateusz Viste
Le #16597661
В Понедельник 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
koollman+nntp
Le #16598331
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 publiq uement
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...




Il faut quand meme faire attention. L'histoire récente montre que,
quelquefois, une clé ssh n'est pas la solution la plus sécure ...
(debian et la faille openssh).

Je n'ai pas de probleme avec un acces ssh en login+mot de passe,
si le mot de passe est raisonnablement complexe. Et le fait que
ce soit un acces distant ajoute pas mal de contraintes, par exemple
il n'est pas envisageable a l'heure actuelle de tester plusieur
millions de clés par seconde sur un accès ssh.

--
Thomas Samson
A witty saying proves nothing, but saying something pointless gets
people's attention.
Publicité
Poster une réponse
Anonyme