Merci. J'avais tout simplement oublié l'option -P 22 du client... faut
pas faire dix trucs en même temps :(
Merci : ça marche nickel...
Le mer. 19 déc. 2018 à 12:36, Olivier Allard-Jacquin
<olivieraj@???> a écrit :
>
> 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 !!
>
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:patrice.karatchentzeff@gmail.com
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_)
