Ssh -X son lancement vous paraît-il "sécurisé" ?

loreleil · Février 21, 2016, 12:32pm

Salut,

ssh -X est opérationnel, je crois … selon vous ma connexion est elle sécurisée ?

Comment m’en assuré ?

J’ai pu lancer virtualbox (création d’un VM squeeze, pour l’heure)

Mais ça rame dur quand même …

[code]loreleil@pc-2-loreleil:~$ ssh -X -vv user@91.x.x.x

…

debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Linux mon_domaine.com 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux

server :
ip : 91.x.x.x
hostname : mon_domaine.com

Last login: Sun Jun 24 13:10:11 2012 from alille-x.x.x.x.w2-5.abo.wanadoo.fr
Linux mon_domaine.com 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux

server :
ip : 91.x.x.x
hostname : mon_domaine.com

user@mon_domaine:~$
[/code]

user@mon_domaine:~$ echo $DISPLAY localhost:10.0 user@mon_domaine:~$

[code]user@mon_domaine:~$ virtualbox
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40350
debug2: fd 7 setting O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 1: rcvd adjust 41512
debug2: channel 1: window 2044252 sent adjust 52900
debug2: channel 1: window 2031616 sent adjust 49152
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40351
debug2: fd 8 setting O_NONBLOCK
debug1: channel 2: new [x11]
debug1: confirm x11
debug2: channel 1: window 2031616 sent adjust 49152
debug2: channel 1: window 1952120 sent adjust 144288
debug2: channel 2: rcvd adjust 42692
debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40352
debug2: fd 9 setting O_NONBLOCK
debug1: channel 3: new [x11]
debug1: confirm x11
debug2: channel 3: rcvd eof
debug2: channel 3: output open -> drain
debug2: channel 3: obuf empty
debug2: channel 3: close_write
debug2: channel 3: output drain -> closed
debug1: channel 3: FORCE input drain
debug2: channel 3: ibuf empty
debug2: channel 3: send eof
debug2: channel 3: input drain -> closed
debug2: channel 3: send close
debug2: channel 3: rcvd close
debug2: channel 3: is dead
debug2: channel 3: garbage collecting
debug1: channel 3: free: x11, nchannels 4
debug2: channel 2: rcvd eof
debug2: channel 2: output open -> drain
debug2: channel 2: obuf empty
debug2: channel 2: close_write
debug2: channel 2: output drain -> closed
debug1: channel 2: FORCE input drain
debug2: channel 2: ibuf empty
debug2: channel 2: send eof
debug2: channel 2: input drain -> closed
debug2: channel 2: send close
debug2: channel 2: rcvd close
debug2: channel 2: is dead
debug2: channel 2: garbage collecting
debug1: channel 2: free: x11, nchannels 3
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40353
debug2: fd 8 setting O_NONBLOCK
debug1: channel 2: new [x11]
debug1: confirm x11
debug2: channel 2: rcvd adjust 42692
debug2: channel 2: rcvd eof
debug2: channel 2: output open -> drain
debug2: channel 2: obuf empty
debug2: channel 2: close_write
debug2: channel 2: output drain -> closed
debug1: channel 2: FORCE input drain
debug2: channel 2: ibuf empty
debug2: channel 2: send eof
debug2: channel 2: input drain -> closed
debug2: channel 2: send close
debug2: channel 2: rcvd close
debug2: channel 2: is dead
debug2: channel 2: garbage collecting
debug1: channel 2: free: x11, nchannels 3
debug2: channel 1: window 2035600 sent adjust 61552
debug2: channel 1: window 2031616 sent adjust 65536
debug2: channel 1: window 2031616 sent adjust 65536

…

debug2: channel 1: send close
user@mon_domaine:~$ debug2: channel 1: rcvd close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
user@mon_domaine:~$[/code]

J’ai relancé une nouvelle session avec l’option -C pour la compression du flux (?) (je crois)

loreleil@pc-2-loreleil:~$ ssh -X -vv -C user@91.x.x.x
Peut on améliorer cette connexion ?

Bien le merci à vous …

etxeberrizahar · Février 21, 2016, 12:32pm

Si tu pousses la parano, tu pourrais même te méfier du ssh à la sauce debian ou linux en général et opter pour ssh sur NetBSD ou OpenBSD …

On te recommande d’utiliser ssh -X plutôt que xhost pour cette simple raison : ssh est crypté, X ne l’est pas.
De plus, si tu as interdit le login de root à ssh, changé de port par défaut, installé fail2ban, empeché le login par mot de passe et exige la clé préalable … la porte de ssh ne s’ouvrira pas en un claquement de doigt (mot de passe “sésame ouvre-toi”).

loreleil · Février 21, 2016, 12:32pm

Salut,

[quote=“etxeberrizahar”]Si tu pousses la parano, tu pourrais même te méfier du ssh à la sauce debian ou linux en général et opter pour ssh sur NetBSD ou OpenBSD …

On te recommande d’utiliser ssh -X plutôt que xhost pour cette simple raison : ssh est crypté, X ne l’est pas.
De plus, si tu as interdit le login de root à ssh, changé de port par défaut, installé fail2ban, empeché le login par mot de passe et exige la clé préalable … la porte de ssh ne s’ouvrira pas en un claquement de doigt (mot de passe “sésame ouvre-toi”).[/quote]

Grrr … tu parles d’un suppositoire, tes propos vont à l’encontre de ce que j’avais cru comprendre sur le nain.

ssh crypté oui d’accord, mais ssh -X alors là, sur le cul! Je suis.

La manière dont tu me présentes le bébé, laisse à supposer de changer d’OS.

On m’aurait menti …

Sinon, ne peut on faire mieux, ssh -X Debian …

Je vais m’enquérir du ssh sur NetBSD ou OpenBSD.

Merci etxeberrizahar …

etxeberrizahar · Février 21, 2016, 12:32pm

Tout le contraire, ne pas offrir X à la terre entière et ne pas trop s’inquiéter du manque de “sécurité” de ssh.

Je ne me suis sans doute pas exprimé clairement en laissant entendre que X n’est pas crypté. Précisons donc.

X seul à base de xhost et de export DISPLAY n’est pas crypté.
X avec ssh est crypté.

ssh -X a le mérite de crypter X, les données transitant par l’obfuscation de ssh.
ssh -X est la méthode qui est la plus recommandée dès lors que tu opères sur le réseau mondial.
En un réseau “de confiance”, réseau local cloisonné avec un bon débit, xhost et l’export de display sont suffisants.

Grhim · Février 21, 2016, 12:32pm

de toutes manières, dans tout les cas, avec du temps, le MITM reste possible contre xssh …le plus sûr reste les BSD

loreleil · Février 21, 2016, 12:32pm

Non! C’est moi le mal embouché!

D’autant plus que …

Source: linux-kheops.com/doc/howto/MINI. … pps-6.html

[quote=“Vincent Zweije”]Trop peu de gens semble réaliser que permettre l’accès à leur unité d’affichage pose des problèmes de sécurité. Quelqu’un qui dispose d’un accès à votre unité d’affichage peut lire et écrire sur vos écrans, lire vos frappes au clavier, et suivre les déplacements de votre mulot.

La plupart des serveurs disposent de deux manières d’authentifier les demandes de connexions qui arrivent : le mécanisme de la liste d’hôtes (xhost) et le mécanisme du mot de passe secret (magic cookie) (xauth). De plus, il y a ssh, l’interpréteur de commande sécurisé, qui peut acheminer les connexions X.

Xhost permet les accès basés sur les nom d’hôtes. Le serveur entretient une liste des hôtes qui sont autorisés à se connecter à lui. Il peut aussi désactiver complètement la vérification des hôtes. Attention : cela signifie que plus aucun contrôle n’est effectué, et donc, que n’importe quel hôte peut se connecter!
[/quote]
Sérénité!

Merci pour ces précisions …

[quote=“Grhim”]de toutes manières, dans tout les cas, avec du temps, le MITN reste possible contre xssh
[/quote]
MITN ? Sa vit pas dans l’eau ça, non …

piratebab · Février 21, 2016, 12:32pm

En plus des conseils habituels (limiter les services ayant accés au net, ne pas autoriser ssh à se connecter en root …), tu peux passer à une authentification par cltf.
doc.fedora-fr.org/wiki/SSH_:_Aut … r_cl%C3%A9

Grhim · Février 21, 2016, 12:32pm

Non! C’est moi le mal embouché!

D’autant plus que …

Source: linux-kheops.com/doc/howto/MINI. … pps-6.html

[quote=“Vincent Zweije”]Trop peu de gens semble réaliser que permettre l’accès à leur unité d’affichage pose des problèmes de sécurité. Quelqu’un qui dispose d’un accès à votre unité d’affichage peut lire et écrire sur vos écrans, lire vos frappes au clavier, et suivre les déplacements de votre mulot.

La plupart des serveurs disposent de deux manières d’authentifier les demandes de connexions qui arrivent : le mécanisme de la liste d’hôtes (xhost) et le mécanisme du mot de passe secret (magic cookie) (xauth). De plus, il y a ssh, l’interpréteur de commande sécurisé, qui peut acheminer les connexions X.

Xhost permet les accès basés sur les nom d’hôtes. Le serveur entretient une liste des hôtes qui sont autorisés à se connecter à lui. Il peut aussi désactiver complètement la vérification des hôtes. Attention : cela signifie que plus aucun contrôle n’est effectué, et donc, que n’importe quel hôte peut se connecter!
[/quote]
Sérénité!

Merci pour ces précisions …

[quote=“Grhim”]de toutes manières, dans tout les cas, avec du temps, le MITN reste possible contre xssh
[/quote]
MITN ? Sa vit pas dans l’eau ça, non …[/quote]

MITM

numerama.com/f/118612-t-evit … n-ssh.html

wiki.backtrack-fr.net/index.php/Ettercap-ng

loreleil · Février 21, 2016, 12:35pm

Salut,

[quote=“etxeberrizahar”]ssh est crypté, X ne l’est pas.
[/quote]

C’est là ou j’ai fait l’amalgame.

L’alchimie de mon neurone a été court-circuiter à ce niveau, un bon deux semaines à farfouiller sur le nain, ssh -X, me hantait les nuits.

Et oui, j’aurais dû faire l’association de X, pour l’environnement X Window.

Quant à vous, @piratebab et @Grhim, merci pour ces liens incontournables, bien Cool!

Merci, je vous en serre cinq …