Harvey,

Thanks for suggesting the "ssh -Y".  That works (as done "ssh -X") but unfortunately it doesn't solve my problem. We are trying to drop X2Go into an existing environment as a replacement for a current solution, and can't force a change in how users connect to the remote machines. For X2Go we really need to figure out how to get this working with a simple "xhost +" and "setenv DISPLAY host:display".

Interestingly, it looks like freenx/opennx work fine in this mode, but we would prefer not to use that solution as it appears to be a dead end.  There must be something different about how freenx/opennx set up security vs X2Go, but I can't find much documentation on configuring security in X2Go.

I'll spend some more time in the man pages, but any other suggestions here would be greatly appreciated.

Thanks

On Wednesday, December 4, 2013 8:22 PM, Harvey Eneman <harvey.eneman@oracle.com> wrote:

If you haven't already, I suggest that use "ssh -Y" to setup trusted X11 forwarding when you connect to the remote linux box from a terminal window (eg. xterm) on the "local" linux host.  This will set the DISPLAY environment variable to a local display on the remote host that is securely forwarded to local linux host for display on the Windows machine.

On 12/4/13, 5:53 PM, Nick Ingegneri wrote:

Can anybody assist me with debugging what I am doing wrong in this case?

I am running the X2Go client in Window 7 and the X2Go server on a RedHat 6 machine. I would like to have a remote linux host export the display back to the X2Go server, which would then forward it to the Windows 7 client.

Starting a new X2Go session, this works on the local host:

[user@localmachine ~]$ echo $DISPLAY :84 [user@localmachine ~]$ xhost + access control disabled, clients can connect from any host [user@localmachine ~]$ xclock # note - the xclock starts without problems

But on a remote host, I found I could not connect to that display, even with "xhost +" already set:

[user@remotemachine ~]$ setenv DISPLAY localmachine:84 [user@remotemachine ~]$ xclock Error: Can't open display: localmachine:84 [user@remotemachine ~]$

As an experiment, I tried setting the DISPLAY on localmachine to use the hostname, after which it could not connect to the display:

user@localmachine ~]$ setenv DISPLAY localmachine:84 [user@localmachine ~]$ xclock Error: Can't open display: localmachine:84 [user@localmachine ~]$ xhost xhost:  unable to open display "localmachine:84"

I'm probably missing something obvious, but don't have any idea what is misconfigured.

Thanks!

---

X2Go-User mailing list X2Go-User@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-user

X2Go-User mailing list X2Go-User@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-user

All,

I think I found the problem, but I'm not sure how to fix it.

Note the options that nxagent.bin is running with:

nxagent.bin -extension XFIXES -extension GLX -nolisten tcp -R -auth /home/testuser/.Xauthority -geometry 800x600 -name X2GO-testuser-97-1386279395_stRxterm_dp32 :97 The "-nolisten tcp" option is preventing the Xserver from receiving any connections via TCP, so it doesn't appear to matter what I do with xhost or xauth.

Is there a configuration file I can change to remove this option?

Thanks, Nick

On Thursday, December 5, 2013 8:59 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

Hi Nick,

On  Do 05 Dez 2013 16:46:02 CET, Nick Ingegneri wrote:

Thanks for suggesting the "ssh -Y".  That works (as done "ssh -X")  but unfortunately it doesn't solve my problem. We are trying to drop  X2Go into an existing environment as a replacement for a current  solution, and can't force a change in how users connect to the  remote machines. For X2Go we really need to figure out how to get  this working with a simple "xhost +" and "setenv DISPLAY  host:display".

Running xhost + on a multi-user host is not a good idea, at all. If  that is your setup of convenience, change it, as it 100% lacks  security. People can access each others' clipboards and read+write  content to/from it. Easily, one can sniff passwords etc. that get  copied to the clipboard, etc.

Interestingly, it looks like freenx/opennx work fine in this mode,  but we would prefer not to use that solution as it appears to be a  dead end.  There must be something different about how freenx/opennx  set up security vs X2Go, but I can't find much documentation on  configuring security in X2Go.

You probably have to play with the xauth command for making your  desired setup work. (Though xhost + makes xauth unnecessary, so maybe  not).

I'll spend some more time in the man pages, but any other  suggestions here would be greatly appreciated.

Greets, Mike

DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31

mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...

Harvey, et al.,

Thanks for the suggestion Harvey.

I confirm that commenting out the "-nolisten tcp" in '/usr/bin/x2gostartagent' resolved the problem we were seeing and allowed us to move forward with our evaluation.

Thanks, Nick

On Thursday, December 5, 2013 10:44 PM, Harvey Eneman <harvey.eneman@oracle.com> wrote:

To remove the "-nolisten tcp", you can simply comment out the assignment in the nx2gostartagent script.

On 12/5/13, 2:13 PM, Nick Ingegneri wrote:

All,

I think I found the problem, but I'm not sure how to fix it.

Note the options that nxagent.bin is running with:

nxagent.bin -extension XFIXES -extension GLX -nolisten tcp -R -auth /home/testuser/.Xauthority -geometry 800x600 -name X2GO-testuser-97-1386279395_stRxterm_dp32 :97 The "-nolisten tcp" option is preventing the Xserver from receiving any connections via TCP, so it doesn't appear to matter what I do with xhost or xauth.

Is there a configuration file I can change to remove this option?

Thanks, Nick

On Thursday, December 5, 2013 8:59 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote: Hi Nick,

On  Do 05 Dez 2013 16:46:02 CET, Nick Ingegneri wrote:

...

Thanks for suggesting the "ssh -Y".  That works (as done "ssh -X")  but unfortunately it doesn't solve my problem. We are trying to drop  X2Go into an existing environment as a replacement for a current  solution, and can't force a change in how users connect to the  remote machines. For X2Go we really need to figure out how to get  this working with a simple "xhost +" and "setenv DISPLAY  host:display".

Running xhost + on a multi-user host is not a good idea, at all. If  that is your setup of convenience, change it, as it 100% lacks  security. People can access each others' clipboards and read+write  content to/from it. Easily, one can sniff passwords etc. that get  copied to the clipboard, etc.

...

Interestingly, it looks like freenx/opennx work fine in this mode,  but we would prefer not to use that solution as it appears to be a  dead end.  There must be something different about how freenx/opennx  set up security vs X2Go, but I can't find much documentation on  configuring security in X2Go.

You probably have to play with the xauth command for making your  desired setup work. (Though xhost + makes xauth unnecessary, so maybe  not).

...

I'll spend some more time in the man pages, but any other  suggestions here would be greatly appreciated.

Greets, Mike

X2Go-User mailing list X2Go-User@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-user