Cant Run X applications residing on Gentoo box via SSH

[bhar99328]

For some time now, I have been unable to run any x applications ON MY GENTOO MACHINES ONLY remotely through ssh. I can successfully connect to X servers on other machines. On the command line I use "ssh -X" to connect, I have set sshd_config's X11Forwarding to yes, I have confirmed that my hosts.allow is allowing traffic from my network in, and I can run KDE and all other apps fine LOCALLY. After ssh'ing into my gentoo box from another machine, if I try to run an x application, I get the following message:

Code: Select all

_X11TransSocketOpen: socket() failed for tcp
_X11TransSocketOpenCOTSClient: Unable to open socket for tcp
_X11TransOpen: transport open failed for tcp/localhost:10
Error: Can't open display: localhost:10.0

I have searched all over trying to find this problem on the net, but have been unsuccessful. I NEED to be able to run programs remotely. I have also tried using xhost and exporting DISPLAY, but I get the same error no matter what. I am really frustrated with this and would appreciate any input. I don't have the time to rebuild my Gentoo boxes so I really need to find the actual cause of this problem. Thanks in advance.

[fimblo]

1) is the display number correct? (in your error message it was 10)
2) for sshd to forward X11, you need ForwardAgent yes set in your local /etc/ssh/ssh_config, and X11Forwarding yes in your remote /etc/ssh/sshd_config file (yeah i saw you set the latter on)
3) xhost and DISPLAY are variables I normally dont set anymore, those can be used to transfer X info without ssh. besides, xhost is a huge security hole, it gives rights to all users on a machine...

But the last two points are academic, since you can get it to work to other systems.

I guess the most suspicious factor in your error message is still the display number of 10. ignore my comment if your system has several users (or actually several X processes, or tightVNC or something). But otherwise you might be trying to send X data from the remote puter to a non-existent display.

dunno. hope this helps
[/b]

[grant.mcdorman]

1) is the display number correct? (in your error
message it was 10)

This should be correct - on the remote system, ssh sets the display number to 10.

Another possiblity to check is to see if the '-nolisten tcp' option is being used. On the system with the X server, run:

Code: Select all

netstat --listening --inet --tcp

If the X server is listening on display 0, you should see as part of the output:

Code: Select all

tcp        0      0 *:6000                  *:*                     LISTEN

If you don't see this, then the X server was started with -nolisten tcp, and any amount of fiddling with ssh options won't get it to work. To fix this, look for the configuration file for your display manager (xdm: /etc/X11/xdm/Xservers; KDE kdm: /usr/kde/3.1/share/config/kdm/Xservers; I'm not sure about gdm) and check the command line in that file.

[sschlueter]

If you don't see this, then the X server was started with -nolisten tcp, and any amount of fiddling with ssh options won't get it to work.

I have read this several times already but the listening port is not needed.

[grant.mcdorman]

If you don't see this, then the X server was started with -nolisten tcp, and any amount of fiddling with ssh options won't get it to work.

I have read this several times already but the listening port is not needed.

Interesting. I tested this out, and you're correct. Apparently the ssh client forwards the TCP connection on the remote host to the Unix domain (non-TCP) socket on the local host. The ssh/sshd manual page does not make it clear that this happens, though.

2) for sshd to forward X11, you need ForwardAgent yes set in your local /etc/ssh/ssh_config

This doesn't appear to be necessary, from my tests (one can either set this option or use the command-line -X option). X11Forwarding in sshd_config is indeed necessary, though.

The display number of 10 comes from this sshd_config parameter:

Code: Select all

X11DisplayOffset
	Specifies the first display number available for sshd 's X11 forwarding. This prevents sshd from interfering with real X11 servers. The default is 10.

bhar99328, when you use ssh -X to connect, this is from an xterm-type application (e.g. konsole), right? (i.e. DISPLAY is automatically set to :0 before you run ssh.) What is the value of DISPLAY before you ssh to the remote system? What does netstat --listening --inet --tcp on the remote system show (after you ssh)?

Presumably, you are not manually setting DISPLAY to localhost:10 on the remote host.

By the way, I cannot get an error identical to yours; most applications produce a different (and shorter) error. What application are you trying to run on the remote host?

[bhar99328]

I am in Konsole when I ssh -X into my gentoo boxes.

Before I ssh, my DISPLAY is :0.0
After I ssh, DISPLAY becomes localhost:10.0
I do not set DISPLAY manually.

netstat --listening --inet --tcp shows:

Code: Select all

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:32769                 *:*                     LISTEN
tcp        0      0 *:723                   *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 localhost:631           *:*                     LISTEN
tcp        0      0 localhost:6010          *:*                     LISTEN

Also, the application I ran to get that error is xclock. I could do it with a KDE application, but then I get all the KDE garbage in addition to this X error.

Now, I don't think this will matter, but I do not have DNS on my network, so /etc/hostname has just 'localhost' inside. But I don't believe this ever affected any of my Red Hat / Mandrake / Debian installs.

Thanks

[alinv]

Try setting the DISPLAY variable to

Code: Select all

inet/localhost:10

It seems to be a ipv6 feature/bug on linux

[bhar99328]

That fixed it. Do you know how I could set ssh to do that for me?

Thanks much.

[alinv]

I'm still looking for that...no luck so far

[grant.mcdorman]

That fixed it. Do you know how I could set ssh to do that for me?

Thanks much.

Perhaps ssh won't do it, but since the remote login via ssh is always a full login you can try this:

Create ~/.bash_profile, if it doesn't exist.

In it put:

Code: Select all

expr "$DISPLAY" : "localhost:" >/dev/null && DISPLAY="inet/$DISPLAY"

as a single line.

That will detect DISPLAY="localhost:something" when you login, and change it appropriately.

(Presumably the reason I didn't see this, by the way, is that I don't have IPV6 code turned on. In most cases, this code isn't very useful, especially in North America, where I am, as the ISPs rarely support it. Presumably you have a need for it, though.)

[alinv]

(Presumably the reason I didn't see this, by the way, is that I don't have IPV6 code turned on. In most cases, this code isn't very useful, especially in North America, where I am, as the ISPs rarely support it. Presumably you have a need for it, though.)

Believe me, I didn't touch any option regarding ipv6 on my system(s), not even for fun.
I will try your solution first thing in the morning

Thanks,
Alin

[grant.mcdorman]

(Presumably the reason I didn't see this, by the way, is that I don't have IPV6 code turned on. In most cases, this code isn't very useful, especially in North America, where I am, as the ISPs rarely support it. Presumably you have a need for it, though.)

Believe me, I didn't touch any option regarding ipv6 on my system(s), not even for fun.
I will try your solution first thing in the morning

Thanks,
Alin

It must be turned on in your kernel, though. The option is Networking Options, The IPv6 protocol (EXPERIMENTAL). Go to /usr/src/linux and check it via make menuconfig or make xconfig. I just checked, and I do have it off. OTOH, if you do have it off, things are seriously weird.

[alinv]

OTOH, if you do have it off, things are seriously weird.

Well then, they are weird:

Code: Select all

# CONFIG_IPV6 is not set

[alinv]

In it put:

Code: Select all

expr "$DISPLAY" : "localhost:" >/dev/null && DISPLAY="inet/$DISPLAY"

as a single line.

That will detect DISPLAY="localhost:something" when you login, and change it appropriately.

Works like a charm!

Thanks a lot
Alin

[duffolonious]

Ok guys, don't force a change in the display variable.

Instead change your "sshd_config" on the remote machine.

#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes

uncomment the lines and change X11Forwarding to yes

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

That should work, if it doesn't and you login to the remote machine with the -X option then feel free to complain.

Now I just need to find out why MozillaFirebird is killing on machine and not the other.

Just to make sure I get this. The Xclient on the remote machine sends it's info across the ssh connection to the local machines Xserver, and displays the remote program. Therefore I don't need the remote program on the local system?

The ssh debugs don't seem to help.

Have a nice day, hopefully I'm helpful...

[grant.mcdorman]

Ok guys, don't force a change in the display variable.

Instead change your "sshd_config" on the remote machine.

#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes

uncomment the lines and change X11Forwarding to yes

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

That should work, if it doesn't and you login to the remote machine with the -X option then feel free to complain.

He did do this. The problem is that, for some reason, 'locahost:10' does not work (it appears that the X clients are using the wrong transport - ipv6 or some other odd variation instead of standard ipv4), but 'inet/localhost:10' does. Since ssh sets the display to 'localhost:10', he needs to prepend 'inet/'.

Now I just need to find out why MozillaFirebird is killing on machine and not the other.

Just to make sure I get this. The Xclient on the remote machine sends it's info across the ssh connection to the local machines Xserver, and displays the remote program. Therefore I don't need the remote program on the local system?

Correct; the remote program runs entirely on the remote system, and only sends its graphics (UI) to the local system.

When you say MozillaFirebird is killing, what does this mean? What happens?

[bartmank]

I have run into a problem getting a smooth X11 forwarding session working on a RH-7.2 box.

The option in sshd_config for X11UseLocalhost yes is not valid. If i issue the command:

Code: Select all

env DISPLAY="localhost:10.0" xclock

on the remote RH box, it works though.

Any ideas?

[poisson]

So DISPLAY variable syntax has changed, interesting...

Such thing broken many programs, first of all xdm/kdm/gdm.
I can't login remotely anymore, so I'm re-emerging xfree
without "ipv6" in USE to test if it's really the bad thing.

Stay tuned !

EDIT:
The trick worked: removing "ipv6" from USE, no more errors appeared in /var/log/kdm.log
I can't say if two "ipv6" machines work.