X starten van andere linux plek wil niet lukken

[Justin_Time]

Dag mensen,

Ik heb hier 2 PC's verbonden met een netwerkje en krijg daar naar 1 kant X niet goed over.

De verbinding zelf gaat over ssh waarbij is Xforward heb aangezet.

De ene is een Suse7.2 bakje en de andere een Debian Woody 3.0 (stable)

Elke keer wanneer ik van de debian bak naar de suse bak ssh'd en daar bijvoorbeeld mozilla start dan gaat ie bezig zijn en krijg ik als laatste commentaar
xmsg: could not open display
error Can't open display carbon:0.0

Doe ik het van de andere kan af dus van de suse naar de debian dan gaat het wel goed.

Ik heb bij allebei de machines al een xhost + gegegeven maar dit mag niet baten.

Dus het lijkt wel alsof de debian machine de display blokkeerd o.i.d.

Het zal wel een hele kleine optie zijn, maar kan het maar niet vinden... iemand een idee?

[odysseus]

Debian laat standaard geen connecties naar X over het netwerk toe, dus je zult dat inderdaad even in moeten stellen. Iets als 'dpkg-reconfigure xserver-xfree86' biedt geloof ik de optie om het te wijzigen, anders moet je even in /etc/X11/ gaan rondneuzen.

[Justin_Time]

'dpkg-reconfigure xserver-xfree86' zie ik niet de optie bijzitten en in de X11 directory staat zoveel, heb ze ook allemaal doorgelezen maar kan de optie maar nie vinden.

[deadinspace]

Als je X over ssh tunnelt dan hoeft dat niet aan te zetten in X. Die optie bij X (nolisten gebeuren) is alleen als je direct over het netwerk wil.

Doe je wel ssh -X ?

[Justin_Time]

nee doe geen -X misschien is dat het..

[Justin_Time]

nee maar telnet wel een sun verder dus dat zou dan weer direct moeten gaan...

[deadinspace]

Justin_Time schreef op 29 oktober 2002 @ 17:09:
nee doe geen -X misschien is dat het..

Misschien is het een idee om dat even te proberen dan

[Justin_Time]

JAh ok, maar ut heeft geen zin.... misschien stom dat ik het vergeten heb te vertellen maar de ssh verbinding is alleen vanaf het internet naar de debian bak en vandaar een telnet naar de suse machine.

Dus het gaat wel gewoon over het netwerk heen...

[deadinspace]

Ehm, dan zou je ssh -X debianbak moeten doen, en dan telnet susebak en dan iets van DISPLAY=debianbak:10 progsel.
Volgensmij is het eenvoudiger als je op die SuSE bak ook ff sshd installeert.

Bovendien: wil je dit over een gewone kabel of ADSL verbinding doen, met dus een zeer beperkte upload? Dan is het waarschijnlijk ook aan te raden om de -C flag bij ssh te gebruiken (dan doettie compressie).

[Onno]

Justin_Time schreef op 29 oktober 2002 @ 19:47:
JAh ok, maar ut heeft geen zin.... misschien stom dat ik het vergeten heb te vertellen maar de ssh verbinding is alleen vanaf het internet naar de debian bak en vandaar een telnet naar de suse machine.

Dus het gaat wel gewoon over het netwerk heen...

Standaard opent sshd een listener voor X op localhost. Dat werkt dus niet als je nog verder gaat telnetten. Er is een optie om de listener op * te openen, kijk maar even in de manpage van sshd. Ik weet zo 1-2-3 niet welke optie het is.

[Justin_Time]

jah maar ik heb zo het idee dat het daar niet aan ligt, want als ik lokaal op de debianbak zit en ik telnet naar de susebak dan werkt het ook niet. ook niet als ik doe: (csh) setenv DISPLAY debianbak:0.0

[Verwijderd]

als je xdm of kdm draait dan moet je in de Xservers file -nolisten tcp uitzetten, als je direct over een netwerk je X wilt benaderen en niet door een directe ssh tunnel (ssh -X):
/etc/kde3/kdm/Xservers
/etc/X11/xdm/Xservers

[Onno]

Justin_Time schreef op 29 oktober 2002 @ 20:44:
jah maar ik heb zo het idee dat het daar niet aan ligt, want als ik lokaal op de debianbak zit en ik telnet naar de susebak dan werkt het ook niet. ook niet als ik doe: (csh) setenv DISPLAY debianbak:0.0

Maar is alles met xauth dan wel goed geregeld? (ik weet niet of telnet wel xauth entries maakt zoals ssh, ik verwacht eigenlijk van niet)

[Justin_Time]

Verwijderd schreef op 29 oktober 2002 @ 20:48:
als je xdm of kdm draait dan moet je in de Xservers file -nolisten tcp uitzetten, als je direct over een netwerk je X wilt benaderen en niet door een directe ssh tunnel (ssh -X):
/etc/kde3/kdm/Xservers
/etc/X11/xdm/Xservers

Dit klinkt wel goed ja, alleen wanneer ik de bestanden aanpast en herstart start mijn X niet meer:

Er stond in:
/etc/kde2/kdm/Xservers
":0 local@tty1 /usr/X11R6/bin/X -dpi 100 -nolisten tcp vt7"
Hiervan heb ik gemaakt
":0 local@tty1 /usr/X11R6/bin/X -dpi 100 vt7"
of
":0 local@tty1 /usr/X11R6/bin/X :0 vt7 bpp24"

Maar dit wil niet werken.. scherm flikkert een paar keer als ik startX doet en knalt met een error dat ie een module niet kan laden eruit. (oude manier werkte het wel)

in /etc/X11/xdm/Xservers stond

":0 local /usr/X11R6/bin/X vt7 -dpi 100 -nolisten tcp"

nu
:0 local /usr/X11R6/bin/X :0 vt7 -bpp 24 heb ook al geprobeerd alleen -nolisten tcp weg te halen nu starten ze niet op...

Ik gebbruik trouwens standaard kdm

[Verwijderd]

wazig, wat voor een error geeft hij dan?

[Justin_Time]

nou het werkt nu iets beter....
lokaal wil het allemaal lukken nadat ik in de Xservers de -nolisten tcp heb weggehaald.

Maar gaan we inloggen via buiten is het weer die cannot open display ...:0.0 (via exceed)

[Verwijderd]

eerst even op de client kijken of je een LISTENING poortje '6000' hebt; vervolgens telnet je naar de x-server en 'export DISPLAY=[xxx.xxx.xxx.xxx]:0.0 (xxx.... staat natuurlijk voor ip)
en start je x-sessie. Wees er zeker van dat er geen firewall tussen zit die '6000' verkeer tegenhoudt.
Nu ben ik geen debian-kenner, maar misschien moet je op de client nog iets als 'xhost +' ingeven.

[deadinspace]

En je moet natuurlijk wel naar het display dat geforward is over ssh connecten ( :10 oid), niet naar het display van de X server die op de Debian bak draait ( :0 ). Hoef je verder -nolisten gebeuren ook niet voor uit te zetten, aangezien dat alleen geldt als je het op de X server op de Debian bak wilt toveren.

Het is volgensmij echt driehonderd keer makkelijker om gewoon even sshd op die SuSE bak te installen (is sowieso een goed idee), en dan van buitenaf met ssh -X op de Debian bak in te loggen en dan met ssh -X weer door naar de SuSE bak te gaan.

[Justin_Time]

uhm ok, we zijn weer wat verder... dat naar die suse bak met ssh -X werkt i.d.d. maar nog steeds niet via telnet.. er staat geen firewall tussen en in me /etc/services staat ook 6000 goed.

Nu met de display op :10 zetten werkt het ook niet... (hoe kan ik zien welke display het moet zijn)

Dat met telnet is essenstieel voor mij omdat dit met de suse bak is om te testem maar de applicatie die echt nodig is draait op een sun welke geen sshd draait en waar ik ook geen toegang voor heb om het erop te zetten.
en ik heb natuurlijk xhost + gedaan

[deadinspace]

Ah, zo.

"ssh -X debianbak" en dan "echo $DISPLAY" doen. En ik denk dat je op dat display "xhost +" moet doen.

[Verwijderd]

Zodra je 'ssh -X' gebruikt zul je zien dat de DISPLAY-var. verwijst naar localhost met een bepaalde offset. Door 'export DISPLAY' te gebruiken verwijs je X naar een andere host en deze zal 'proberen' verbinding te maken op poort 6000 van de andere host.
M.a.w. controleer of poort 6000 open staat voordat je de telnet-sessie start; telnet-sessie starten; export DISPLAY=.....; x-sessie starten.

[Justin_Time]

nou dit is echt irri ....

oke even stap voor stap wat ik doe misschien helpt dit:

1:
start exceed
2:
ik putty naar de debian bak (ssh (2) met X forwarding en compressie)
daar is mijn display localhost:10.0 (ip is 10.32.0.26)
3:
xhost + (dus alles staat open)
4:
telnet 10.32.0.153 (de sun)
5:
hier is mijn DISPLAY localhost:10.0 dus hier doe ik (csh)
setenv DISPLAY 10.32.0.26:10.0
6:
ik start de applicatie
nu krijg ik "Error: Cant't open display: 10.32.0.26:10.0


Maak ik hier nou een denkfout ergens?

[Verwijderd]

probeer eens 'setenv DISPLAY 10.32.0.26:0.0'

[Verwijderd]

Justin_Time schreef op 29 oktober 2002 @ 14:45:
xmsg: could not open display
error Can't open display carbon:0.0
Doe ik het van de andere kan af dus van de suse naar de debian dan gaat het wel goed.

Debian geeft standaard de -nolisten tcp optie mee aan de X server waardoor ie niet op TCP/6000 gaat luisteren naar binnenkomende X-connecties en remote X of X-fowarding dus ook niet werkt.

In /etc/X11 even 'rgrep -i 'nolisten tcp' *' tikken. Bij mij staat 't in /etc/X11/gdm/gdm.conf, omdat die de X-server start en ik gdm gebruik om in te loggen.

[Justin_Time]

Verwijderd schreef op 01 november 2002 @ 16:23:
probeer eens 'setenv DISPLAY 10.32.0.26:0.0'

Xlib: client is not authorized to connect to Server
Error Can't open display 10.32.0.26:0.0

[Justin_Time]

Verwijderd schreef op 01 november 2002 @ 16:43:
[...]


Debian geeft standaard de -nolisten tcp optie mee aan de X server waardoor ie niet op TCP/6000 gaat luisteren naar binnenkomende X-connecties en remote X of X-fowarding dus ook niet werkt.

In /etc/X11 even 'rgrep -i 'nolisten tcp' *' tikken. Bij mij staat 't in /etc/X11/gdm/gdm.conf, omdat die de X-server start en ik gdm gebruik om in te loggen.

Deze stond er bij mij ook nog inderdaad, maar na het verwijderen van deze -no listen tcp (ook in het begin geloof bij XAcces weggehaald)
nog steeds het zelfde verhaal bij de :0.0 de no authorisation en bij de 10:0 gewoon van Can't

Ik heb nu wel nog iets ontdekt als ik bij de debvianbak de xhost + geef dan staat er netjes.

access control disabled, clients can connect from any host

maar de tweede regel daaronder staat:
xhost: must be on local machine to enable or disable access control.

Zal dit het zijn?
en kan ik hier omheen?

[odysseus]

Hmm, dat is vervelend. Je kunt natuurlijk simuleren dat je een lokale gebruiker bent door je xhost-commando in een script te zetten en dat door cron te laten draaien of zo, maar echt netjes is het niet . Waarschijnlijk ligt daar in ieder geval je probleem.

[Justin_Time]

hmm cron he... goed idee ga het even proberen

[Justin_Time]

Nou dit werkt ook nog niet.

* * * * * /usr/bin/xhost +

cron doet dit netjes (doe er ook een touch bij en die zie ik)

Maar krijg nog steeds bij de sun bij 10:0 can't open en bij de :0.0 Not authorised

[deadinspace]

Verwijderd schreef op 01 november 2002 @ 16:23:
probeer eens 'setenv DISPLAY 10.32.0.26:0.0'

Ehm, :0.0 is de X server (if any) op de Debian bak. Daar moet het beeld niet heen, het beeld moet naar de virtuele X server die sshd heeft gecreëerd, en die hangt op :10.0 .

Verwijderd schreef op 01 november 2002 @ 16:43:
Debian geeft standaard de -nolisten tcp optie mee aan de X server waardoor ie niet op TCP/6000 gaat luisteren naar binnenkomende X-connecties en remote X of X-fowarding dus ook niet werkt.

Alleen heeft XFree er verder dus niks mee te maken volgensmij. Het gaat hier om sshd, die moet de X connecties accepteren, niet XFree.

[Justin_Time]

Alleen heeft XFree er verder dus niks mee te maken volgensmij. Het gaat hier om sshd, die moet de X connecties accepteren, niet XFree.

Tja... nog ideeen dan? Xforwarding staat aan en kan niks vinden qua athorisatie wat erop kan duiden dat ie uhm blokkeerd.

[deadinspace]

Ik heb het zelf ook even geprobeerd, en het probleem is vrij duidelijk. Dit ben ik, met ssh -X ingelogd op mijn gateway:

code:

[marcelm@anything marcelm]$ echo $DISPLAY
localhost:10.0
[marcelm@anything marcelm]$ nmap -p 6000-6050 127.0.0.1

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on anything (127.0.0.1):
(The 50 ports scanned but not shown below are in state: closed)
Port       State       Service
6010/tcp   open        unknown                 

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
[marcelm@anything marcelm]$ nmap -p 6000-6050 192.168.0.1

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
All 51 scanned ports on anything.nowhere (192.168.0.1) are: closed

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
[marcelm@anything marcelm]$

Kortom: sshd luistert voor X connecties alleen op lo (loopback device), niet op externe interfaces. Dit doen ze waarschijnlijk om security redenen. De vraag is: hoe krijg je sshd zover dat het wel werkt?

Ik zie een paar mogelijkheden:

* sshd schoppen dat hij ook op externe interfaces luistert. Manpages lezen, zoeken met google ofzo... Niet onmogelijk dat er gewoon een optie voor is in de configfile.

* ssh installeren op die sun bak. Dat kan als het goed is ook als user, al zul je hem dan vanuit je homedir moeten draaien en laten luisteren op een poort > 1024 (dus niet de standaard poort 22)

* Zelf iets bouwen waardoor je wel op de sshd op je Debian bak kunt connecten. Ik denk daarbij aan een netcat constructie (een netcat die luistert op 6011 op alle interfaces, gepiped naar eentje die praat naar 6010 op localhost), of (wat netter) wat portmapping met je firewall op je Debian bak.

[Blubber]

Ik wil niet veel zeggen, maar ik heb hier X-forwarding via ssh dus, van een Slackware 8.1 naar Solaris aan de gang door gewoon op de server in /etc/ssh/sshd_config ergens X-forwarding aan te zetten...

[deadinspace]

Alleen is dat niet het probleem, en dat had je geweten als je de thread goed gelezen had.

[Justin_Time]

uhm even kijken

code:

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Interesting ports on localhost (127.0.0.1):
(The 50 ports scanned but not shown below are in state: closed)
Port       State       Service
6000/tcp   open        X11


Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds   

Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
carbonix:/home/justin# nmap -p 6000-6050 193.172.67.34

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Interesting ports on carbonix.onat.unisource.nl (193.172.67.34):
(The 50 ports scanned but not shown below are in state: closed)
Port       State       Service
6000/tcp   open        X11


Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
carbonix:/home/justin#   

carbonix:/home/justin# nmap -p 6000-6050 10.32.0.26

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Interesting ports on  (10.32.0.26):
(The 50 ports scanned but not shown below are in state: closed)
Port       State       Service
6000/tcp   open        X11


Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds

10.32.0.26 is interne netwerk
de 193 gaat naar het netwerk waar port 22 is geforward en de internetverbinding vandaan komt.

Dus dit lijkt het probleem niet