Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 24-02-2017 12:50:33

debianux
Membre
Distrib. : debian-jessie-8.7_LVM-chiffré_dual-boot-uefi-w10
Noyau : Linux 4.7.0-0.bpo.1-amd64
(G)UI : Xfce 4.10
Inscription : 19-05-2014

[recit] connexion vnc, en ssh, de deux pc sur réseau local

Bonjour,

dans l'objectif de pouvoir, à la demande, apporter, à distance, une aide à un utilisateur d'un pc 'distant', je vous raconte ici comment j'ai passé, (non sans mal smile), une première étape :

connexion vnc, en ssh, de deux pc, sous debian-jessie-8.7, connectés à une box, sur un même réseau local .

la méthode et/ou le récit peut comporter des oublis ou des points améliorables et les suggestions sont les bienvenues smile

pc-server= pc que l'on veut voir (pour intervenir et aider) = nc10cha2 avec un user 'sg'
pc-viewer= pc sur lequel on voit pc-server et sur lequel on peut intervenir à distance = t460s avec un user 'sg'

1/ installation de openssh-server et x11vnc sur pc-server

voir: https://debian-facile.org/doc:reseau:ssh:serveur

. changer le numéro de port: 22 en xxxxx supérieur à 1024 et inférieur à 65535, ici: 12345
. au cas où le pc-server ne serait pas reconnu par son 'hostname', j'ai passé son ip, via l'interface de la box (livebox2 dans mon cas) / avancé / dhcp) en ip fixe.
. dans le firewall, ici de ma livebox, créer ou modifier le port 'ssh' pour indiquer et 'accepter' le nouveau numéro.
(pour une connexion à un pc situé ailleurs que sur le réseau local, il faudra faire de même sur le firewall distant).

2/ installation de openssh-client et vncviewer sur pc-viewer

voir: https://debian-facile.org/doc:reseau:ssh:client

générer la paire de clés, l'exporter et utiliser 'ssh-agent'

3.1/ sur le pc viewer : terminal-1 : ouverture en ssh du pc server via x11vnc :

sg@t460s:

 ssh -p 12345 -t -L 5900:localhost:5900 nc10cha2 'x11vnc -localhost -display :0'



Debian GNU/Linux 8
Enter passphrase for key '/home/sg/.ssh/id_rsa':
###############################################################
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@#
#@                                                           @#
#@  **  WARNING  **  WARNING  **  WARNING  **  WARNING  **   @#
#@                                                           @#
#@        YOU ARE RUNNING X11VNC WITHOUT A PASSWORD!!        @#
#@                                                           @#
#@  This means anyone with network access to this computer   @#
#@  may be able to view and control your desktop.            @#
#@                                                           @#
#@ >>> If you did not mean to do this Press CTRL-C now!! <<< @#
#@                                                           @#
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@#
#@                                                           @#
#@  You can create an x11vnc password file by running:       @#
#@                                                           @#
#@       x11vnc -storepasswd password /path/to/passfile      @#
#@  or   x11vnc -storepasswd /path/to/passfile               @#
#@  or   x11vnc -storepasswd                                 @#
#@                                                           @#
#@  (the last one will use ~/.vnc/passwd)                    @#
#@                                                           @#
#@  and then starting x11vnc via:                            @#
#@                                                           @#
#@      x11vnc -rfbauth /path/to/passfile                    @#
#@                                                           @#
#@  an existing ~/.vnc/passwd file from another VNC          @#
#@  application will work fine too.                          @#
#@                                                           @#
#@  You can also use the -passwdfile or -passwd options.     @#
#@  (note -passwd is unsafe if local users are not trusted)  @#
#@                                                           @#
#@  Make sure any -rfbauth and -passwdfile password files    @#
#@  cannot be read by untrusted users.                       @#
#@                                                           @#
#@  Use x11vnc -usepw to automatically use your              @#
#@  ~/.vnc/passwd or ~/.vnc/passwdfile password files.       @#
#@  (and prompt you to create ~/.vnc/passwd if neither       @#
#@  file exists.)  Under -usepw, x11vnc will exit if it      @#
#@  cannot find a password to use.                           @#
#@                                                           @#
#@                                                           @#
#@  Even with a password, the subsequent VNC traffic is      @#
#@  sent in the clear.  Consider tunnelling via ssh(1):      @#
#@                                                           @#
#@    http://www.karlrunge.com/x11vnc/#tunnelling            @#
#@                                                           @#
#@  Or using the x11vnc SSL options: -ssl and -stunnel       @#
#@                                                           @#
#@  Please Read the documention for more info about          @#
#@  passwords, security, and encryption.                     @#
#@                                                           @#
#@    http://www.karlrunge.com/x11vnc/faq.html#faq-passwd    @#
#@                                                           @#
#@  You are using the -localhost option and that is a good   @#
#@  thing!! Especially if you ssh(1) into this machine and   @#
#@  use port redirection.  Nevertheless, without a password  @#
#@  other users could possibly do redirection as well to     @#
#@  gain access to your desktop.                             @#
#@                                                           @#
#@  To disable this warning use the -nopw option, or put     @#
#@  'nopw' on a line in your ~/.x11vncrc file.               @#
#@                                                           @#
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@#
###############################################################
22/02/2017 16:48:59 x11vnc version: 0.9.13 lastmod: 2011-08-10  pid: 2588
22/02/2017 16:48:59 Using X display :0
22/02/2017 16:48:59 rootwin: 0x7f reswin: 0x4600001 dpy: 0x9cd4c20
22/02/2017 16:48:59
22/02/2017 16:48:59 ------------------ USEFUL INFORMATION ------------------
22/02/2017 16:48:59 X DAMAGE available on display, using it for polling hints.
22/02/2017 16:48:59   To disable this behavior use: '-noxdamage'
22/02/2017 16:48:59
22/02/2017 16:48:59   Most compositing window managers like 'compiz' or 'beryl'
22/02/2017 16:48:59   cause X DAMAGE to fail, and so you may not see any screen
22/02/2017 16:48:59   updates via VNC.  Either disable 'compiz' (recommended) or
22/02/2017 16:48:59   supply the x11vnc '-noxdamage' command line option.
22/02/2017 16:48:59
22/02/2017 16:48:59 Wireframing: -wireframe mode is in effect for window moves.
22/02/2017 16:48:59   If this yields undesired behavior (poor response, painting
22/02/2017 16:48:59   errors, etc) it may be disabled:
22/02/2017 16:48:59    - use '-nowf' to disable wireframing completely.
22/02/2017 16:48:59    - use '-nowcr' to disable the Copy Rectangle after the
22/02/2017 16:48:59      moved window is released in the new position.
22/02/2017 16:48:59   Also see the -help entry for tuning parameters.
22/02/2017 16:48:59   You can press 3 Alt_L's (Left "Alt" key) in a row to
22/02/2017 16:48:59   repaint the screen, also see the -fixscreen option for
22/02/2017 16:48:59   periodic repaints.
22/02/2017 16:48:59
22/02/2017 16:48:59 XFIXES available on display, resetting cursor mode
22/02/2017 16:48:59   to: '-cursor most'.
22/02/2017 16:48:59   to disable this behavior use: '-cursor arrow'
22/02/2017 16:48:59   or '-noxfixes'.
22/02/2017 16:48:59 using XFIXES for cursor drawing.
22/02/2017 16:48:59 GrabServer control via XTEST.
22/02/2017 16:48:59
22/02/2017 16:48:59 Scroll Detection: -scrollcopyrect mode is in effect to
22/02/2017 16:48:59   use RECORD extension to try to detect scrolling windows
22/02/2017 16:48:59   (induced by either user keystroke or mouse input).
22/02/2017 16:48:59   If this yields undesired behavior (poor response, painting
22/02/2017 16:48:59   errors, etc) it may be disabled via: '-noscr'
22/02/2017 16:48:59   Also see the -help entry for tuning parameters.
22/02/2017 16:48:59   You can press 3 Alt_L's (Left "Alt" key) in a row to
22/02/2017 16:48:59   repaint the screen, also see the -fixscreen option for
22/02/2017 16:48:59   periodic repaints.
22/02/2017 16:48:59
22/02/2017 16:48:59 XKEYBOARD:
22/02/2017 16:48:59 Switching to -xkb mode to recover these keysyms:
22/02/2017 16:48:59    xkb  noxkb   Keysym  ("X" means present)
22/02/2017 16:48:59    ---  -----   -----------------------------
22/02/2017 16:48:59     X           0x40  at
22/02/2017 16:48:59     X           0x23  numbersign
22/02/2017 16:48:59     X           0x5b  bracketleft
22/02/2017 16:48:59     X           0x5d  bracketright
22/02/2017 16:48:59     X           0x7b  braceleft
22/02/2017 16:48:59     X           0x7d  braceright
22/02/2017 16:48:59     X           0x7c  bar
22/02/2017 16:48:59     X           0x5c  backslash
22/02/2017 16:48:59
22/02/2017 16:48:59   If this makes the key mapping worse you can
22/02/2017 16:48:59   disable it with the "-noxkb" option.
22/02/2017 16:48:59
22/02/2017 16:48:59
22/02/2017 16:48:59 X FBPM extension not supported.
22/02/2017 16:48:59 X display is capable of DPMS.
22/02/2017 16:48:59 --------------------------------------------------------
22/02/2017 16:48:59
22/02/2017 16:48:59 Default visual ID: 0x21
22/02/2017 16:48:59 Read initial data from X display into framebuffer.
22/02/2017 16:48:59 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/4096
22/02/2017 16:48:59
22/02/2017 16:48:59 X display :0 is 32bpp depth=24 true color
22/02/2017 16:48:59
22/02/2017 16:48:59 Autoprobing TCP port
22/02/2017 16:48:59 Autoprobing selected TCP port 5900
22/02/2017 16:48:59 Autoprobing TCP6 port
22/02/2017 16:48:59 Autoprobing selected TCP6 port 5900
22/02/2017 16:48:59 listen6: bind: Address already in use
22/02/2017 16:48:59 Not listening on IPv6 interface.
22/02/2017 16:48:59
22/02/2017 16:48:59 Xinerama is present and active (e.g. multi-head).
22/02/2017 16:48:59 Xinerama: number of sub-screens: 1
22/02/2017 16:48:59 Xinerama: no blackouts needed (only one sub-screen)
22/02/2017 16:48:59
22/02/2017 16:48:59 fb read rate: 133 MB/sec
22/02/2017 16:48:59 fast read: reset -wait  ms to: 10
22/02/2017 16:48:59 fast read: reset -defer ms to: 10
22/02/2017 16:48:59 The X server says there are 16 mouse buttons.
22/02/2017 16:48:59 screen setup finished.
22/02/2017 16:48:59
22/02/2017 16:48:59 WARNING: You are running x11vnc WITHOUT a password.  See
22/02/2017 16:48:59 WARNING: the warning message printed above for more info.
22/02/2017 16:48:59

The VNC desktop is:      localhost:0
PORT=5900

******************************************************************************
Have you tried the x11vnc '-ncache' VNC client-side pixel caching feature yet?

The scheme stores pixel data offscreen on the VNC viewer side for faster
retrieval.  It should work with any VNC viewer.  Try it by running:

    x11vnc -ncache 10 ...

One can also add -ncache_cr for smooth 'copyrect' window motion.
More info: http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching


*** lorsque le terminal-2 est lancé avec vncviewer :



22/02/2017 17:09:38 Got connection from client ::1
22/02/2017 17:09:38   other clients:
22/02/2017 17:09:38 Normal socket connection
22/02/2017 17:09:38 check_access: client addr ::1 is local.
22/02/2017 17:09:38 Disabled X server key autorepeat.
22/02/2017 17:09:38   to force back on run: 'xset r on' (3 times)
22/02/2017 17:09:38 incr accepted_client=1 for ::1:36368  sock=12
22/02/2017 17:09:38 Client Protocol Version 3.8
22/02/2017 17:09:38 Protocol version sent 3.8, using 3.8
22/02/2017 17:09:38 rfbProcessClientSecurityType: executing handler for type 1
22/02/2017 17:09:38 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8
22/02/2017 17:09:38 Pixel format for client ::1:
22/02/2017 17:09:38   8 bpp, depth 6
22/02/2017 17:09:38   true colour: max r 3 g 3 b 3, shift r 4 g 2 b 0
22/02/2017 17:09:38 Enabling full-color cursor updates for client ::1
22/02/2017 17:09:38 Enabling NewFBSize protocol extension for client ::1
22/02/2017 17:09:38 Using ZRLE encoding for client ::1
22/02/2017 17:09:38 copy_tiles: allocating first_line at size 33
22/02/2017 17:09:39 Pixel format for client ::1:
22/02/2017 17:09:39   32 bpp, depth 24, little endian
22/02/2017 17:09:39   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
22/02/2017 17:09:39 no translation needed
22/02/2017 17:09:39 Enabling full-color cursor updates for client ::1
22/02/2017 17:09:39 Enabling NewFBSize protocol extension for client ::1
22/02/2017 17:09:39 Switching from ZRLE to hextile Encoding for client ::1
22/02/2017 17:09:42 client useCopyRect: ::1 -1
22/02/2017 17:09:42 client_set_net: ::1  0.0001
22/02/2017 17:09:42 created   xdamage object: 0x4600024
22/02/2017 17:09:43 client 1 network rate 2012.5 KB/sec (4660.3 eff KB/sec)
22/02/2017 17:09:43 client 1 latency:  3.0 ms
22/02/2017 17:09:43 dt1: 0.0191, dt2: 0.0893 dt3: 0.0030 bytes: 215025
22/02/2017 17:09:43 link_rate: LR_LAN - 2 ms, 2012 KB/s
22/02/2017 17:09:48 created selwin: 0x4600025
22/02/2017 17:09:48 called initialize_xfixes()


*** à la fermeture du vncviewer :


22/02/2017 17:10:24 cursor_noshape_updates_clients: 0
22/02/2017 17:10:24 cursor_noshape_updates_clients: 0
22/02/2017 17:10:27 cursor_noshape_updates_clients: 0
22/02/2017 17:10:37 cursor_noshape_updates_clients: 0
22/02/2017 17:11:47 client_count: 0
22/02/2017 17:11:47 Restored X server key autorepeat to: 1
22/02/2017 17:11:47 viewer exited.
22/02/2017 17:11:47 deleted 32 tile_row polling images.
Connection to nc10cha2 closed.
 



'Connection to nc10cha2 closed.' : après un 'ctrl+c' sur le terminal-2: vncviewer

3.2/ lancement vncviewer sur pc-viewer dans terminal-2 :

sg@t460s:

vncviewer localhost:0



VNC Viewer Free Edition 4.1.1 for X - built Apr  2 2015 21:51:06
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.

Wed Feb 22 17:09:22 2017
 CConn:       connected to host localhost port 5900
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 6 (8bpp) rgb222
 CConn:       Using ZRLE encoding
 CConn:       Throughput 14285 kbit/s - changing to hextile encoding
 CConn:       Throughput 14285 kbit/s - changing to full colour
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using hextile encoding
 ^C
Wed Feb 22 17:11:31 2017
 main:        CleanupSignalHandler called
 



nb: '^C' ou 'ctrl+c' : pour stopper vnc, quand on a fini l'opération de sauvetage smile

4/ on peut également utiliser le gui 'ssvnc' (à installer via les dépots) : 'ssl/ssh vnc viewer' :

. vnc host:display =localhost:0
. option: 'use ssh'
. connect

nb: bug? si on clique sur 'options', la fenêtre 'ssl/ssh vnc viewer' se ferme mais la vue du 'vnc-server' est toujours active.

des infos complémentaires:
http://www.karlrunge.com/x11vnc/ssvnc.html#tsvnc

5/ on verra après pour la seconde étape : connexion 'vraiment' à distance smile

atfu_a-toutes-fins-utiles
debianux

Hors ligne

#2 24-02-2017 13:46:43

otyugh
CA Debian-Facile
Lieu : Quimperlé/Arzano
Distrib. : Debian Stable
Inscription : 20-09-2016
Site Web

Re : [recit] connexion vnc, en ssh, de deux pc sur réseau local

La part "mauvaise" de ce procédé c'est que tu as un accès ssh openbar au client, ce qui est un problème de sécurité pour lui, et de principe pour toi. De plus en réseau, cela nécessite de la part du client d'avoir une règle NAT pour que tu puisses contacter son serveur SSH. Ça me semble être une mauvaise solution si ce n'est pas quelqu'un que tu connais déjà intimement et qui a toute confiance -et limite même. Tu pourrais réduire la surface de permission, mais ça reste un peu problématique.

C'est pour ça que je préfère le reverse SSH en un sens x).
...Ça fait partit de mes projets de le faire "en interface graphique" qui est en plan depuis un moment :x

Dernière modification par otyugh (24-02-2017 13:48:59)


Agenda du libre : dépannage par des bénévoles pour tout le monde !
Arzano Informatique : dépannage gagne-pain.
Liste de balados (aussi dit "podcast") : emissions audio pro/amateur

Hors ligne

#3 24-02-2017 16:17:27

debianux
Membre
Distrib. : debian-jessie-8.7_LVM-chiffré_dual-boot-uefi-w10
Noyau : Linux 4.7.0-0.bpo.1-amd64
(G)UI : Xfce 4.10
Inscription : 19-05-2014

Re : [recit] connexion vnc, en ssh, de deux pc sur réseau local

Bonjour otyugh !

.pour toi,

accès ssh openbar au client

, le client c'est le 'pc-server' de ce 'récit' ?

.

ce qui est un problème de sécurité pour lui

: pourrait-il être 'attaqué' par qqn d'autre, dans la mesure où la connexion ssh est 'sécurisée' par clé publique détenue par le pc-server ?

.

De plus en réseau, cela nécessite de la part du client d'avoir une règle NAT pour que tu puisses contacter son serveur SSH

: dans le cas présent, il n'y en a pas et ça passe.
ce serait différent entre deux box ?

.

je préfère le reverse SSH

: je ne suis pas arrivé à la faire fonctionner, notamment en m'appuyant sur ce tuto :
https://forum.ubuntu-fr.org/viewtopic.php?id=1916741
dont je n'ai pas réussi à tirer la 'substantifique moelle' smile

Hors ligne

#4 24-02-2017 17:02:22

otyugh
CA Debian-Facile
Lieu : Quimperlé/Arzano
Distrib. : Debian Stable
Inscription : 20-09-2016
Site Web

Re : [recit] connexion vnc, en ssh, de deux pc sur réseau local

>pour toi,"accès ssh openbar au client", le client c'est le 'pc-server' de ce 'récit' ?

Alors ça peut sembler un peu confus, le vulnérable, c'est le serveur SSH qui accepte la connexion, celui qui est en client SSH a au contraire tout pouvoir sur celui qui "accueil". Sauf si bien sûr on mets des restrictions (ça se fait dans /etc/ssh/sshd_config ou par clé dans ~/.authorized_key)

>dans la mesure où la connexion ssh est 'sécurisée' par clé publique détenue par le pc-server ?

C'est pas le danger de l'extérieur que je pensais, plus le fait que toi te connectant à l'autre et lui lançant x11vnc, tu peux aussi faire plein d'autres choses : copier son dossier photo chez-toi par exemple tongue

>"De plus en réseau, cela nécessite de la part du client d'avoir une règle NAT pour que tu puisses contacter son serveur SSH": dans le cas présent, il n'y en a pas et ça passe.ce serait différent entre deux box ?

En réseau local il n'y en a pas besoin. En réseau "internet" oui, y a besoin d'une telle règle. Quand on s'adresse à ton ip publique 1.2.3.4 sur le port 80, comment ta box saurait à qui adresser les paquets ? Vu que tu as plein de choses connectés en local. Tu es obligé de dire explicitement à ta box "les gens qui te contactent sur le port machin, tu le renvoie à mon serveur web dont l'ip est 192.168.1.2" - par exemple.

>je ne suis pas arrivé à la faire fonctionner, notamment en m'appuyant sur ce tuto :

Après chacun ses besoins. je préférerais te donner mon script fini que te donner des critiques abstraites, mais l'est en pause depuis quelques mois faute à ma désorganisation chronique ><

Dernière modification par otyugh (24-02-2017 17:04:47)


Agenda du libre : dépannage par des bénévoles pour tout le monde !
Arzano Informatique : dépannage gagne-pain.
Liste de balados (aussi dit "podcast") : emissions audio pro/amateur

Hors ligne

#5 24-02-2017 19:06:08

debianux
Membre
Distrib. : debian-jessie-8.7_LVM-chiffré_dual-boot-uefi-w10
Noyau : Linux 4.7.0-0.bpo.1-amd64
(G)UI : Xfce 4.10
Inscription : 19-05-2014

Re : [recit] connexion vnc, en ssh, de deux pc sur réseau local

c'est avec plaisir que je le testerai : pense à mettre une annonce ici smile

Hors ligne

Pied de page des forums