Re: Joindre une machine derrière un proxy ou dansun LAN non …

Page principale

Répondre à ce message
Auteur: Olivier Allard-Jacquin
Date:  
À: GUILDE
Anciens-sujets: Re: Joindre une machine derrière un proxy ou dans un LAN non routable
Nouveaux-sujets: Re: Joindre une machine derrière un proxy ou dans un LAN non routable
Sujet: Re: Joindre une machine derrière un proxy ou dansun LAN non routable
    Bonjour Patrice,

Le 18/12/2018 à 14:50, Patrice Karatchentzeff a écrit :
> Aïe, ce n'est pas si simple que je pensais...
>
> J'ai un autre routeur entre chez moi et le portable : je suppose qu'il
> s'agit du cas ta présentation p43.


    Ne prends pas en compte la page 42:
http://olivieraj.free.fr/fr/linux/information/prise_en_main_a_distance_avec_linux/presentation/img42.html


    C'est ma configuration perso que j'ai donné en exemple:
- où le "routeur" en bleu et à gauche, est **une machine Linux**
- sur laquelle se connecte l'utilisateur "newbee" (à droite)
- et moi, je me connecte sur ce "routeur linux", avec ma propre machine.
L'intérêt, c'est que sur ce "routeur linux", je n'y dépose pas ma clé
privée SSH qui me permet de me connecter à la machine de "newbee". Donc
en cas de piratage de "routeur linux", l'attaquant ne peut pas récupérer
cette clé, qui donne un accès complet à la machine de "newbee"
- c'est inutilement compliqué par rapport à ce dont tu as besoin. Voir
plus bas pour la suite.


> J'ai un autre souci : ce routeur est déjà configuré pour rerouter les
> connexions ssh sur mon poste... donc tous les connexions au port 22
> sont renvoyées sur ma machine.


    Ce n'est pas un problème, et c'est au contraire bien ce qu'il faut faire


> Je ne comprends pas ce que « voit » les machines individuellement. À
> la sortie du premier tunnel (donc du portable vers mon "premier point
> d'arrivée") :
>
> 1 - on a un flux en TCP ouvert sur le port 22
> 2 - en théorie, le serveur ssh à l'arrivée "comprend" et renvoie deux
> flux en TCP sur les port 10022 et 10900 (si on a choisi ces deux-là
> lors du tunnel)
> 3 - il suffit de se brancher dessus avec l'outil ad-hoc sur le
> matériel d'arrivée
>
> Si le matériel d'arrivée est un routeur, il suffit de lui faire
> renvoyer le trafic du port en question (10022) vers celui qu'on a
> envie (monpc:20022). En théorie, ça fonctionne. En pratique non car il
> faut un serveur ssh sur le routeur pour interpréter la deuxième étape.
> (dans les faits, j'ai testé et effectivement, ça ne fonctionne pas).
>
> Or, d'après ton crobar, ça fonctionne... Quel est le truc que je n'ai pas pigé ?


    Dans ton cas, tu dois utiliser la page 38:
http://olivieraj.free.fr/fr/linux/information/prise_en_main_a_distance_avec_linux/presentation/img38.html


Le fait que tu ais ta box ADSL qui soit entre ta machine et internet n'a
pas d'importance, du moment que tu as bien fait la redirection du port 22.

Mais note : certains FAI font du filtrage de ports, et parfois le 22 ne
passe pas
- Aussi, une astuce consiste à ouvrir le port 443 du routeur, et le
rediriger vers le port 22 de ton ordi. L'utilisateur à distance
utilisera alors l'option "-p 443", ou "-oPort=443" du client SSH.
- Certes, le SSL (HTTPS/443) et le SSH (22) ne sont pas la même chose,
mais si le FAI ne pousse pas trop la "deep inspection", il n'y voit que
du feu ... :)

Bon, résumons les étapes:
- Informations:
Ton utilisateur à distance est newbee@BigServer
Il se connecte sur TA machine (ThinClient)


- Etape 1:
Tu dois créer un compte "newbee" sur TA machine ("Thinclient")
Cet utilisateur doit pouvoir faire du "TcpForwarding" (pour le
paramètres "-R" de sa connexion SSH), mais c'est assez dangereux, car il
peut alors faire du "-L", ce qui veut dire qu'il peut rediriger TES
PORTS sur SA machine. C'est pas cool du tout, car il peut avoir accès à
tes partages SMB, NFS, et autre ...
C'est pourquoi j'ai trouvé une astuce afin de limiter cette intrusion.
Ci-dessous un extrait de mon "/etc/ssh/sshd_config":

# 2011/03/13: Change settings for "remote access" users
Match group remote_u
PasswordAuthentication no

# Chroot unsecure users...
ChrootDirectory /chroot/remote_access

# Allow TCP formwarding ("ssh -L" option)
AllowTcpForwarding yes

# VERY IMPORTANT:
# Don't forget to restric "ssh -L" feature to an unused, but
# real, port !
# To do this, ~/.ssh/authorized_key lines MUST start with
# 'permitopen="127.0.0.1:65534"'
# Example: permitopen="127.0.0.1:65534" ssh-rsa
AAAAB3.................== user@client

- L'utilisateur fait parti du groupe "remote_u", donc les paramètres
ci-dessus ne s'applique qu'à ce groupe, via l'option "Match group remote_u"
- Je l'isole dans un "chroot". C'est optionnel, mais cela sécurise un
peu plus. Note: C'est chiant à débugger ...
- J'autorise le "AllowTcpForwarding yes". Avec les risques déjà vu
- MAIS il est possible de limiter le paramètre "-L" en bidouillant le
~/.ssh/authorized_key de newbee@ThinClient, comme indiqué en commentaire.


- Etape 2:
L'utilisateur à distance (newbee@bigserver) doit être capable de se
connecter en SSH sur ta machine. Pour cela, il doit lancer :

ssh -p 22 \
    -R 10022:127.0.0.1:22 \
    -R 15900:127.0.0.1:5900 \
     newbee@ThinClient


le "-p 22" peut être remplacé par un "-p 443", comme dit plus haut.

- Etape 3:
L'utilisateur doit lancer un "x11vnc", qui permet de partager son écran.
ATTENTION, cela ne marche pas si il utilise "Wayland" comme serveur
graphique ...

Perso, j'utilise:
screen -m -d -S x11vnc \
x11vnc -noscr -noncache -noxdamage -display :0 -no6 -noipv6 -rfbportv6
-1 -rfbport 5900 -loop -localhost -rfbauth ${HOME}/.vnc/passwd

- Le programme est lancé par un "screen". Ainsi, si son X redémarre, le
x11vnc ne sera pas impacté
- Je désactive IPv6
- En cas de crash de x11vnc, il redémarre tout seul (-loop)
- Il n'écoute que sur son loopback -> Securité en plus
- Son x11vnc est protégé par un mot de passe
- "man x11vnc" pour les autres options

Mais si tu veux faire plus simple, il suffit de lancer :
    x11vnc



- Etape 4:
  Tu te connectes chez lui en SSH, en passant par le port 10022 ouvert
sur TA machine :
    ssh -oPort=10022 newbee@localhost


Note: Ce "newbee"-là est le compte "newbee" de BigServer (la machine à
distance), et non pas le "newbee@thinClient", c'est à dire ta machine

Évidemment, il faut que l'utilisateur à distance ait un serveur SSH
d'ouvert, et configuré pour que tu puisses t'y connecter dessus.


- Etape 5:
Tu te connectes chez lui en vnc, en passant par le port 15900 ouvert
sur TA machine :
xtigervncviewer -PreferredEncoding Tight localhost:10000

Si la connexion ADSL rame, tu peux dégrader la qualité vidéo, pour
utiliser moins de bande passante :
xtigervncviewer -PreferredEncoding Tight -CompressLevel 9
-LowColorLevel 1 -QualityLevel 0 localhost:10000

    Cordialement,


                        Olivier
-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
       /   / \  / \   \   Web:  http://olivieraj.free.fr/
      /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!