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
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.Réponses:
Les sessions ssh ont commencé après avoir changé le fichier / etc / ssh_config du client Mac pour inclure la ligne:
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.
la source
man ssh_configla source
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:
... 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).
...
la source