X11Forwarding cassé par migration stretch/buster

Support Debian
#1

Bonjour,
je viens de migrer mon serveur domestique de stretch en buster et le X11Forwarding ne fonctionne plus quand je me connecte dessus en -X.
Je n’ai pas changé le sshd_config, qui contient bien X11Forwarding yes, et je ne vois pas d’ou ça peut venir.
Une idée ?

emeraude@emeraude:~$ env | grep DISPLAY
DISPLAY=localhost:10.0
emeraude@emeraude:~$ firefox
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
Unable to init server: Type d’affichage Broadway non pris en charge : localhost:10.0
Error: cannot open display: localhost:10.0
#2

Bonjour Mattotop,

Le paquet xauth est-il toujours installé sur ton serveur domestique ?

D’après quelques recherches, il semblerait que c’est l’absence de ce paquet qui provoque cette erreur.

#3

Oui, il l’est, et je l’ai réinstallé, pour être sur.
Ca n’a rien changé.

#4

Sinon, j’ai aussi un peu cherché, mais rien de vraiment probant, il y a peut être un truc avec wayland, vu que mon client et mon serveur sont des machines qui étaient initialement en Xorg et que je me connecte depuis gnome, mais je ne connais pas trop wayland, et je ne sais pas quoi chercher.

#5

C’est plus lié à l’application qu’a openssh le problème.
Il me semble avoir lu des souci avec Wayland et Firefox, mais je ne parviens pas à retrouver où.

#6

Je viens de tester avec un xterm et chromium, c’est pareil.

#7

Salut

Tu as essayé avec -Y ?

Je n’avais jamais vu cette expression :
« Type d’affichage Broadway non pris en charge »

#8

Oui, et -XY

Bah moi non plus, je t’avoue, et c’est un peu ce message “broadway” qui me fait penser à un truc avec wayland, même si c’est ténu comme indice.

#9

Je viens d’essayer dans mon contexte ;

Il faut xauth sur les deux machines.

J’ai eu à placer dans mon /etc/ssh/ssh_config

Host * # à adapter (pas forcément nécessaire cette ligne)
XAuthLocation /usr/bin/xauth # à adapter
ForwardX11Trusted yes
ForwardX11 yes
ForwardAgent yes

Pour une connexion ssh -X simple ;
J’ai lancé Xterm et Opéra.

La conf serveur :

enkod ~ # sed /etc/ssh/sshd_config -e '/^#.*$/d' -e '/^$/d'
PubkeyAuthentication yes
AuthorizedKeysFile	.ssh/authorized_keys
AllowUsers rem@192.168.1.3 rem@192.168.1.18
UsePAM yes
X11Forwarding yes
PrintMotd no
PrintLastLog no
Subsystem	sftp	/usr/lib64/misc/sftp-server
AcceptEnv LANG LC_ALL LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME LANGUAGE LC_ADDRESS LC_IDENTIFICATION LC_MEASUREMENT LC_NAME LC_PAPER LC_TELEPHONE
AcceptEnv COLORTERM
enkod ~ #

C’est du pur Xorg X11 OpenRC par contre

#10

Vérifié et réinstallés sur les deux, que dalle.

Testé sur le client, redémarrage à tous hasards du service ssh, puis testé en ajoutant ça sur le serveur, avec pareil redémarrage à tous hasards, que dalle.

PermitRootLogin	 no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem	sftp	/usr/lib/openssh/sftp-server
Protocol     2

Pas tout à fait la tienne, mais pas super différente pour autant.
Et ça ne passe toujours pas.

#11 
rem@n73sm ~ $ ls -l ~/.Xauthority
-rw------- 1 rem rem 50 26 août  09:41 /home/rem/.Xauthority
rem@n73sm ~ $

C’est un point à vérifier.

C’est du niveau débutant confirmé bon sang :face_with_raised_eyebrow:
https://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong-authentication/

Et les pare-feu ou apparmor, ces trucs que je ne connais pas, ça joue dans l’histoire ?

Aussi : https://forum.ubuntu-fr.org/viewtopic.php?pid=6439141#p6439141

#12

Sur le compte client:

mj@mercure:~$ ls -l ~/.Xauthority
-rw------- 1 mj mj 105 août  26 11:53 /home/mj/.Xauthority

Sur le compte auquel je me connecte sur le serveur:

emeraude@emeraude:~$ ls -l ~/.Xauthority
-rw------- 1 emeraude emeraude 590 août  25 16:46 /home/emeraude/.Xauthority

Ca m’a fait penser à faire un autre test en me reconnectant sur ma machine de départ en -X depuis le serveur, en me disant que client et serveur ne causaient peut être pas la même langue, mais que le client pouvait peut être causer avec lui même, le DISPLAY s’exporte bien, la mécanique de sockets se met en place, mais que dalle niveau auth, c’est pas mieux.

Mais je te pue au nez, non mais !
J’ai pointé toutes les suggestions du lien, tout est normal.

Même levé, ça passe pas.
[edit: levé client >et< serveur]

emeraude@emeraude:~$ ls -lR ~/.dbus
/home/emeraude/.dbus:
total 4
drwx------ 2 emeraude emeraude 4096 sept.  5  2016 session-bus

/home/emeraude/.dbus/session-bus:
total 24
-rw-r--r-- 1 emeraude emeraude 464 mars  13 18:06 ############-0
(...)

Euh. Moi non plus, je n’y connais rien du tout à apparmor, je ne sais pas quoi vérifier.

#13

mes users se nomment rem
et toi tu as mj et emeraude

pour noter une différence.

https://wiki.debian.org/fr/Wayland#FAQ

J’exécute divers programmes sur le réseau, par exemple via le déport d’affichage (X11 forwarding) de ssh, ou xhost. Comment cela fonctionnera-t-il sous Wayland ?

TODO

Capture%20d%E2%80%99%C3%A9cran_2019-08-26_12-41-02

https://debian-facile.org/viewtopic.php?id=15907
https://ubuntuplace.info/questions/329565/where-to-set-gdk-backend

Tu pourrais essayer

GDK_BACKEND=X11 ssh -X emeraude@emeraude

et/ou depuis emeraude

GDK_BACKEND=X11 firefox

J’arrête là, je n’y comprend presque plus rien.
Un peu jeune le Wayland.

#14

Pas mieux, capitaine, pas mieux:

mj@emeraude:~$ xterm
X11 connection rejected because of wrong authentication.
xterm: Xt error: Can't open display: localhost:11.0

tests wayland:
En faisant xhost + sur le client, ça ne fonctionne pas mieux.

emeraude@emeraude:~$ GDK_BACKEND=wayland xterm
X11 connection rejected because of wrong authentication.
xterm: Xt error: Can't open display: localhost:12.0

Pareil avec GDK_BACKEND=X11 avant ssh, et sur serveur.

J’installe task-xfce-desktop sur mon client, et je te dis si ça passe avec une session sans wayland (je ne sais en fait pas si mon gnome est wayland ou pas, mais avec xfce au moins, je serais sur).

#15

Je croyais que le Gnome récent était forcément Wayland
ou pouvait soit être X11, mais au choix de la session GDM3.

#16

C’est possible.
En tous cas, j’avais gnome, gnome-classic, et j’avais déjà kde, en fait, et maintenant aussi xfce, et pareil quelle que soit la session.
Donc à moins que gdm3 (mon greeter actuel) ne lance wayland avant démarrage de la session X, ce n’est pas wayland.
Et au passage, j’ai testé aussi en utilisant un autre user en session client, donc ce n’est pas lié à la config user spécifique.

#17

J’ai ajouté
ForwardAgent yes
à la config ssh client.

Le progrès, je veux bien oui
Mais il y a toujours des plâtres à essuyer…
Et statistiquement il y a une faute “d’orthographe” dans le code toutes les 1000 lignes.

Je crois que tu dois choisir une session X11 explicitement à l’identification GDM3 (avec F1 peut-être)

C’est inattendu que ça ne marche pas avec une session Xfce.
Tu pourrais la forcer en manuel en mode startx

Avec mon système différent, je ne peux plus grand chose pour toi.
Le web dit partout que X11Forwarding et Wayland ne coopèrent pas du tout.
Et il y a un XWayland qui existe.

Gardons le moral :sunglasses:
Il y a peut-être un truc tout bête qui a été oublié…

#18

Il te reste le debug ; il peut pointer du doigt quelque chose…

ssh -vvv
#19

A tester quand je pourrais fermer ma session, là je bosse.

Tu PEUX choisir (par défaut c’est “Gnome” sans plus de précision chez moi), il y a une roue crantée pour sélectionner ta session à la souris.

#20

Salut

Voir connexion GDM3 « Gnome on Xorg »
https://www.debian-fr.org/t/synaptic-ninstalle-aucun-fichier/79985/8?u=r2mi

Pour :

Je voulais dire WTF ou « c’est quoi ce bordel »
Aucunement te critiquer ou remettre en question tes compétences et ton professionnalisme.

Tu n’étais pas visé.
Je t’ai en estime.