[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fw: Re: Starten eines Prog. auf anderem Rechner via X11 Terminal



Also sprach Andreas Pakulat <apaku@gmx.de> (Fri, 27 Jan 2006 00:09:49
+0100):
> On 26.01.06 23:04:41, Richard Mittendorfer wrote:
> > Also sprach Andreas Pakulat <apaku@gmx.de> (Thu, 26 Jan 2006
> > 21:41:07 +0100):
> > Also teste ich das mal mit -nolisten tcp:
> > 
> > 192.168.2.52(libre) X -> 192.168.1.51(breez) sshd
> > sshd[1588]: debug1: x11_create_display_inet: Socket family 10 not
> > supported Das sieht nicht gut aus. Was brauche ich dafuer? im
> > Kernel? ..
> 
> in der Tat, hier:
> 
> Jan 26 23:49:27 neo sshd[9582]: debug1: X11 connection requested.
> Jan 26 23:49:27 neo sshd[9582]: debug1: channel 2: new [X11 connection
> from 127.0.0.1 port 1426]
> 
> Fragen wir mal Tante Google (1. Treffer bei der Fehlermeldung und
> anschliessend im BTS geschaut - 292880):

..

> loopback device ist nicht up and running war dort die Loesung.

Wird's nicht sein, aber danke fuer's nachschauen :) Mein Netz zur
Internetverbindung ist gerade tot, deswegen hab ich das wlan des
Nachbarn gekapert und will dort nicht durch surfern auffallen... 

lo        Protokoll:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:402 errors:0 dropped:0 overruns:0 frame:0
          TX packets:402 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:33149 (32.3 KiB)  TX bytes:33149 (32.3 KiB

> Naechster Ansatz: man socket (ok dafuer braucht man evtl. manpages-dev

Haett' ich schon da, waer nur nie soweit gekommen da nachzusehen. Wieder
was gelernt.

> oder so) liefert den Header sys/socket.h. Dort ist ein Verweis auf
> bits/socket.h und dort ist 10 tatsaechlich drin - PF_INET6. 

sowas hab ich in <$SOURCE/include/linux/socket.h>
...
#define AF_INET6  10 /* IP version 6         */
...
#define PF_INET6  AF_INET6
...

> Jetzt bin ich verwundert, zum einen weil sich die beiden "Loesungen"
> widersprechen - ein wenig - und zum anderen weil hier z.B. auch kein
> IPv6 geht - im Kernel abgeschaltet.

Ich hab's hier auch nicht eingebaut. Ich hab mal sicherheitshalber das
af_keys Modul geladen. Leider ohne Erfolg. Einen Zusammenhang mit der 
.config kann ich mir nur schwer vorstellen.

Da fallt mir ein mich mal auf den lokalen Server (der auch noch X oben
hat) einzuloggen und siehe da: der ssh -X tunnel funktioniert. Dort
liegt aber XFree 4.3.0 -- am Desktop xorg 6.8.2. Die sshd Version ist
ident ist 4.2p1-5 (beide Etch). Es liegt also mal nicht am
Klienten(Xserver).

> > debug1: Authentication succeeded (publickey).
> > debug1: channel 0: new [client-session]
> > debug1: Entering interactive session.
> > debug1: Requesting X11 forwarding with authentication spoofing.
> > debug1: Sending environment.
> > debug1: Sending env LC_ALL = de_AT@euro
> > debug1: Sending env LANG = de_AT@euro
> > ritch@breez:~$ xterm
> > debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max
> > 16384 debug1: client_request_x11: request from 127.0.0.1 33491
> > debug1: channel 1: new [x11]
> > debug1: confirm x11
> > X11 connection rejected because of wrong authentication.
> > debug1: channel 1: free: x11, nchannels 2
> > X connection to localhost:10.0 broken (explicit kill or server
> > shutdown)
> 
> Hmm, ich rate mal: Der ssh-client darf auf dem Rechner an dem du sitzt
> nicht auf X11 zugreifen. Warum: k.A.

Vorallem "wrong authentication" ist mir ein Raetsel. 

DAMN! Mach' ich's mit root ist auch am alles in Ordnung und der Tunnel
tut. Nicht so als User. ~/bashzeugs ist's mal nicht. ~/.Xauthority
sollts doch auch nicht sein. Den Zusammenhang mit xauth verstehe ich
allerdings nicht so recht. Aber immerhin: Ein deutliches Rechteproblem.

> Mal schauen was Tante Google sagt:
> 
> Ein Beitrag in der d-u-g aus 2003 raet zu pruefen ob auf dem
> entfernten Rechner xauth installiert ist und ob ssh darauf zugreifen
> darf. xauth ist in xbase-clients bei Sarge. Bei Sid bin ich grad
> ueberfragt (und zu faul zum nachgucken). Die anderen ersten 5 Einträge
> von google sahen nicht so erfolg-versprechend aus. Ausser vllt:
> 
> http://www.eos.ncsu.edu/remoteaccess/troubleshoot.html
> 
> Aber da darfst du selbst lesen.

:) thx, werd' mich umgehend darum kuemmern.

> > ritch@breez:~$ echo $DISPLAY
> > localhost:10.0          # ist das der lokale ssh tunnel?
> 
> jaein. Also ich kenne mich mit ssh-X11-Forwarding nicht sonderlich
> aus, aber ich vermute das auf der "entfernten" Seite - aka X-Client -
> DISPLAY so gesetzt wird und damit quasi "in den ssh-Tunnel" zeigt. Auf
> der anderen Seite - aka X-Server - wird dann die Eingabe des
> ssh-Tunnels auf das eigentliche DISPLAY (normalerweise 0.0)
> weitergeleitet.

Genau das meinte ich. "Eine Art lokaler Ein-/Ausgang zum Tunnel". 
 
> > > > Noe, es is' was anderes mit dem ich mich vor langer Zeit
> > > > gespielt und scheinbar kaputt gemacht hab.
> > > 
> > > Moeglich, das sshd-Log sollte dir mehr liefern und ssh -v.
> > 
> > Ich's kanns nicht wirklich interpretieren.
> 
> Ooch naja, man muss die Fehlermeldungen nicht immer verstehen,
> manchmal reichts sie bei Google abzuliefern...
> 
> Hoffe dass du es damit findest.

Ich weiss ja garnicht, warum ich mich jetzt darum kuemmere, xdmcp tut ja
perfekt.
 
> Andreas

thx, ritch



Reply to: