Affichage X11 transmis par SSH de Linux vers Mac perdu après un certain temps


10

J'ai un problème nouveau et vexant avec ssh qui transfère ma connexion X11 lors de la connexion d'un Mac (10.7.2) à Linux (Ubuntu 8.04). Je n'ai aucun problème à utiliser ssh -X pour se connecter à la machine distante et démarrer une application basée sur X11 à partir de ce shell.

Ce qui a récemment commencé à se produire, c'est que les appels supplémentaires d'applications X11 à partir de ce même shell, après un certain temps (de l'ordre des heures), ne peuvent pas démarrer car l'affichage transféré est bloqué (je présume). Lorsque je tente de démarrer xterm, par exemple, j'obtiens le message habituel concernant un mauvais paramètre DISPLAY, tel que:

Erreur xterm Xt: impossible d'ouvrir l'affichage: localhost: 10.0

Mais l'application X11 que j'ai lancée juste lorsque je me suis connecté fonctionne toujours très bien, en utilisant exactement le même affichage (localhost: 10.0), juste qu'elle a été démarrée plus tôt.

J'ai activé la journalisation détaillée dans sshd_config et je le vois dans le fichier /var/log/auth.log en réponse à l'échec de la tentative de démarrage de xterm:

sshd [22104]: canal 8: échec d'ouverture: interdiction administrative: échec d'ouverture

Si je ssh -X sur le serveur à nouveau, en démarrant un nouveau shell et en obtenant un nouvel affichage (localhost: 11.0), le même processus se répète: les applications X11 démarrées tôt s'exécutent très bien aussi longtemps que je les laisse ouvertes (jours ), mais après quelques heures, je ne peux plus en démarrer de nouvelles à partir de ce shell.

Particularités: serveur OpenSSH sshd fonctionnant sur Ubuntu 8.04, affichage transmis à un Mac exécutant Lion (10.7.2) avec le serveur Apple X par défaut. Les systèmes sont connectés sur un LAN Ethernet avec un seul commutateur entre eux. Aucune des deux machines n'exécute un pare-feu. Jusqu'à récemment (il y a quelques jours), cette configuration fonctionnait parfaitement, donc je ne sais pas où regarder ensuite. Je ne suis en aucun cas un expert X11 ou SSH mais j'ai une bonne expérience UNIX / Linux. Rien d'évident n'a changé dans la configuration du client ou du serveur bien que j'aie essayé de changer quelques options pour essayer de déboguer cela, comme définir TCPKeepAlive de sshd_config sur no et définir "host + localhost" (vous pouvez dire que j'ai fait une recherche sur Google).

Lorsque vous vous connectez à partir d'un ordinateur portable Linux 11.10 au même hôte distant sur le même réseau et commutateur, ce problème ne se produit pas - un xterm peut être invoqué avec succès des heures plus tard à partir du même shell de connexion ssh tandis que la même expérience à partir du Mac échoue ( testé ce matin pour en être sûr), il semblerait donc que ce soit un problème spécifique à Mac.

Avec "LogLevel DEBUG3" défini sur la machine distante (serveur sshd), et aucune modification effectuée par moi dans les connexions client, /var/log/auth.log montre une légère modification des rapports d'état de la connexion pendant la nuit, qui est le numéro de port utilisé par la seule session ssh réussie de la machine Linux (je pense), connexion # 7 ci-dessous:

sshd [20173]: debug3: canal 7: status: Les connexions suivantes sont ouvertes: \ r \ n # 0 server-session (t4 r0 i0 / 0 o0 / 0 fd 14/13 cfd -1) \ r \ n # 3 Connexion X11 du port 127.0.0.1 57564 (t4 r1 i0 / 0 o0 / 0 fd 16/16 cfd -1) \ r \ n # 4 Connexion X11 du port 127.0.0.1 57565 (t4 r2 i0 / 0 o0 / 0 fd 17 / 17 cfd -1) \ r \ n # 5 Connexion X11 depuis le port 127.0.0.1 57566 (t4 r3 i0 / 0 o0 / 0 fd 18/18 cfd -1) \ r \ n # 6 Connexion X11 depuis le port 127.0.0.1 57567 (t4 r4 i0 / 0 o0 / 0 fd 19/19 cfd -1) \ r \ n # 7 Connexion X11 à partir du port 127.0.0.1 59007

Dans ce rapport, tout est identique entre les rapports d'état, à l'exception du numéro de port utilisé par la connexion # 7 qui, je crois, est le client Linux - le seul qui conserve toujours une connexion d'affichage. Il continue d'augmenter au fil du temps, à en juger par une séquence de ces rapports pendant la nuit.

Merci pour toute aide,

-Mike


Je rencontre le même problème.
churnd

J'ai activé -vvv sur la commande ssh pour obtenir les informations de débogage de la session ssh côté client du Mac. J'ai obtenu ceci: codeConnexion X11 rejetée après expiration de ForwardX11Timeout ForwardX11Timeout est une option du client ssh du Mac qui limite le transfert à partir d'une connexion non approuvée. L'utilisation potentielle de -Y au lieu de -X fonctionnerait. ForwardX11Timeout n'est pas documenté dans la page de manuel ssh de Lion. Sa valeur par défaut semble être de 20 minutes. Il est possible de le définir plus haut dans ssh_config mais le serveur Lion's X se bloque s'il est réglé sur> 596 heures ... qui, en millisecondes, déborde de 31 bits. Arrgh. J'espère que cela le corrige.
mklein9

Réponses:


13

Les sessions ssh ont commencé après avoir changé le fichier / etc / ssh_config du client Mac pour inclure la ligne:

ForwardX11Timeout 596h

fonctionnent tous bien et ont été toute la journée. Désormais, ils auraient tous refusé de lancer de nouveaux xterms. Je pense donc que c'est la réponse, et heureusement une solution simple, mais le délai d'attente se produira toujours dans 3 semaines et demie.


3

man ssh_config

ForwardX11Trusted

Si cette option est définie sur "oui", les clients X11 distants auront un accès complet à l'écran X11 d'origine. Si cette option est définie sur "non", les clients X11 distants seront considérés comme non fiables et empêchés de voler ou de falsifier les données appartenant aux clients X11 de confiance. De plus, le jeton xauth (1) utilisé pour la session sera configuré pour expirer après 20 minutes. Les clients distants se verront refuser l'accès après cette heure. La valeur par défaut est "non" Voir la spécification de l'extension X11 SECURITY pour plus de détails sur les restrictions imposées aux clients non approuvés.


1
Il peut être utile de préciser pourquoi vous pensez que cette option de configuration résoudrait le problème d'origine.
pjmorse

Cela explique pourquoi le problème se produit, mais un raisonnement serait utile.
Stefan Lasiewski

1

Pour ajouter à "répondu le 7 janvier 12 à 0:11 mklein9 28129" "Les sessions ssh ont commencé après que j'ai modifié le fichier / etc / ssh_config du client Mac pour inclure la ligne:

ForwardX11Timeout 596h

... mais le délai d'expiration aura encore lieu dans 3 semaines et demie. "

Apparemment, vous pouvez utiliser 0 et cela définit le délai d'expiration à l'infini (tant que la connexion est activée).

ForwardX11Timeout 0

...

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.