x11 forwarding over ssh not working

[kasse]

I cannot forward x11 from my openbsd 4.4. Not to other computers nor to myself via ssh to localhost. When I try xclock I get- Error: Can't open display.

in sshd_config I set X11UseLocalHost "no" and I log in with ssh -X. I also tried to change the X11DisplayOffset but nothing is working.
I have tried to set the xauth location also but no difference.
I have also tried the ssh -Y option.
When I log in to the freebsd, where it works DISPLAY=localhost:10.0
but when I log in to openbsd, DISPLAY is not set, it does not work if I set it to
localhost:10.0 either.

ps.
I can forward it from my Freebsd with the OpenBsd as the client. However on my Freebsd I cannot forward x11 from my jails. I followed the instructions in the freebsd handbook for the jails.

[Oko]

Is it possible that you disable pf (only if you are on local secure network) and test it without it?
Could you post complete files /etc/ssh/sshd_config and /etc/ssh/ssh_config for both server and client machines?
How does your .Xauthority file on clent machine looks like? Do you use XDM or equivalent? Do you maybe use full Gnome or KDE? on the client machine?

Can you post the message that you get when you try to log with

ssh -Y my.account@my.server

[kasse]

I get the same error- Error: Can't open display.
When you connect to your localhost with -X or -Y do you have DISPLAY set?
It says that the default for X11DisplayOffset is defaulted to 10, is this supposed to set DISPLAY to something? When I am in a regular xterm with no ssh DISPLAY=:0.0, but it is nil in ssh.

sshd(1) says

X11 FORWARDING
     If the ForwardX11 variable is set to ``yes'' (or see the description of
     the -X, -x, and -Y options above) and the user is using X11 (the DISPLAY
     environment variable is set), the connection to the X11 display is auto-
     matically forwarded to the remote side in such a way that any X11 pro-
     grams started from the shell (or command) will go through the encrypted
     channel, and the connection to the real X server will be made from the
     local machine.  The user should not manually set DISPLAY.  Forwarding of
     X11 connections can be configured on the command line or in configuration
     files.

     The DISPLAY value set by ssh will point to the server machine, but with a
     display number greater than zero.  This is normal, and happens because
     ssh creates a ``proxy'' X server on the server machine for forwarding the
     connections over the encrypted channel

How am I supposed to interpret this?

[Oko]

On the server side

in sshd_config I set X11UseLocalHost "no"

That should be set to yes the way that I read which is default value for server side and X11 forwarding should be set to YES as well. Here is part of mine sshd_config which is not altered from the default installation since the only thing I do differently is disabling root login

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes

Commented are default values. When you want something you have to
uncomment and put different value.

On the client side the default values are

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0

I think that ForwardX11 should be set to yes.

To be perfectly honest with you I have not used it for a while so I would have to look man pages and
few books to be able to give you precise answer.
You can do configuration per user so you do not have to alter default values in ssh_config system wide.

[kasse]

Not that I that I have the faintest idea about what I am talking about, but if I set X11UseLocalHost="yes" would that not set the x11 forwarding to loopback. I guess that should work if I try it with connection to local host.

However even with this set to yes (default I guess), it does not work when I connect ssh -X localhost. The display is still not set and I get Error: Can't open display. Is this becaus opening it is not allowed or because it is not set?

Sorry for asking this again but if you do ssh -X localhost and log in is your DISPLAY set?

[phoenix]

X11UseLocalHost isn't the option that needs to be set.

X11Forwarding is the option that allows or prevents X11 forwarding via SSH. If this option is set to no than X11 forwarding is banned. If this option is set to yes, then X11 forwarding is allowed.

It's not rocket science.

[kasse]

Yes it is working now with
X11Forwarding=Yes
X11UseLocalHost=Yes
I always that one or the other set to no.


In order to run X11 applications in a Freebsd jail, that is accessed via ssh -X from the "jail host", must one install Xorg in the jail too?

[phoenix]

The X server runs on the system with the graphics card, so xorg-server only needs to be installed on the local system.

[BSDfan666]

Originally Posted by phoenix

The X server runs on the system with the graphics card, so xorg-server only needs to be installed on the local system.

Phoenix is absolutely correct, the jail need not run an X server.. but X shared libraries/utilities should be installed accordingly.

The process runs inside the jail.. only the X traffic is forwarded over the SSH session.

[kasse]

Thank you for your replies. I have xlock installed in the jail and I looked at http://lists.freebsd.org/pipermail/f...il/000476.html
but it does not help if I set X11UseLocalHost=no as they suggest there. Am I missing something else?

[robbak]

Why do you keep messing around with X11UseLocalhost???? Leave it as the default.

From my quick read of man sshd_config, that variable tells ssh (that is the local client) whether it should bind to the local X11 server on the ssh client, or forward the requests to some other X server on the local network. man sshd tells me that generally there is some scripting magic to set X11UseLocalHost based on what DISPLAY is set to on the local system anyway.

Remove all references to X11UseLocalHost that you have added and leave it that way.

Now, ssh -X remotemachine, and do echo $DISPLAY, Then try an X utility and post us everything that it returns. Also check the log files on the X server and see if the requests have been rejected locally.

[kasse]

First of all I apologize and I hope that my behavior is not harmful to peoples blood pressure or the color of their hair. Secondly I hope that it is okay that this thread in a OpenBSD section, has now shifted to Freebsd questions, now that the OpenBSD problem was solved.

Moderators: I would appreciate a yellow card before an impending ban.

----------------------------------------------------------------------------------------------------------------

The reason I fiddled with the X11UseLocalHost was because, from my understanding, that was the resolution to the problems when you search for "x11 jails ssh".

When I have X11UseLocalHost as the default=yes, and log in from my host 192.168.0.100 to a hosted jail at 192.168.0.105 with ssh -X user@192.168.0.105 and I try xclock, I get this in the jail:

$ xclock
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).
$ echo $DISPLAY
localhost:10.0

I have tried with new .Xauthorities, by deleting them and logging in again, as suggested on some Ubuntu forums.

Finally about logs, I am not certain which log you refer to, but I could not see any errors in auth.log+messages on either system.

[phoenix]

Originally Posted by robbak

Why do you keep messing around with X11UseLocalhost???? Leave it as the default.

From my quick read of man sshd_config, that variable tells ssh (that is the local client) whether it should bind to the local X11 server on the ssh client, or forward the requests to some other X server on the local network. man sshd tells me that generally there is some scripting magic to set X11UseLocalHost based on what DISPLAY is set to on the local system anyway.

Actually, X11UseLocalhost doesn't change which X server is used, it just changes which IPort the proxy X server binds to, and which IPort is used for the DISPLAY environment variable.

With X11UseLocalhost set (the default), the proxy X server binds to 127.0.0.1:6010 and DISPLAY is set to localhost:10.0. With X11UseLocalhost disabled, the proxy X server binds to *:6010 (binds to port 6010 on all IPs) and the DISPLAY is set to :10.0.

The first setting is more secure as only processes running on the system can use the forwarded X port. The second setting is less secure, and any process (local or remote) can (potentially) connect to the forwarded X port.

[robbak]

the log files I would be looking at are /var/log/Xorg.0.log, the console output of the X server, ([ctrl][alt][F1] should get you there, although I do not know where the console output goes if you are using a display manager (kdm, gdm or xdm)

the error messages suggest to me thta you are hitting the X server just fine, but are being rejected by the auth systems.

[kasse]

Originally Posted by robbak

the log files I would be looking at are /var/log/Xorg.0.log, the console output of the X server, ([ctrl][alt][F1] should get you there, although I do not know where the console output goes if you are using a display manager (kdm, gdm or xdm)

the error messages suggest to me thta you are hitting the X server just fine, but are being rejected by the auth systems.

Thanks for the help, there are no errors in the Xorg.0.log.

Here is a list of netstat -an from the freebsd host system, connected to an openbsd computer with ssh -X running xclock fine, and connected to a jail 192.168.0.105 with ssh -X trying to run xclock with no success.

Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp4       0      0 192.168.0.100.58068    192.168.0.103.22       ESTABLISHED
tcp4       0      0 192.168.0.105.6010     *.*                    LISTEN
tcp4       0      0 192.168.0.105.22       192.168.0.105.58498    ESTABLISHED
tcp4       0      0 192.168.0.105.58498    192.168.0.105.22       ESTABLISHED
tcp4       0      0 192.168.0.106.22       *.*                    LISTEN
tcp4       0      0 192.168.0.100.57103    91.197.164.3.80        ESTABLISHED
tcp6       0      0 *.*                    *.*                    CLOSED
tcp6       0      0 *.*                    *.*                    CLOSED
tcp6       0      0 *.*                    *.*                    CLOSED
tcp4       0      0 192.168.0.105.25       *.*                    LISTEN
tcp4       0      0 192.168.0.105.22       *.*                    LISTEN
tcp4       0      0 192.168.0.104.25       *.*                    LISTEN
tcp4       0      0 192.168.0.106.25       *.*                    LISTEN
tcp4       0      0 127.0.0.1.25           *.*                    LISTEN
tcp4       0      0 *.22                   *.*                    LISTEN
tcp6       0      0 *.22                   *.*                    LISTEN
tcp4       0      0 *.*                    *.*                    CLOSED
tcp46      0      0 *.80                   *.*                    LISTEN
tcp46      0      0 *.3306                 *.*                    LISTEN
tcp4       0      0 *.6000                 *.*                    LISTEN
tcp6       0      0 *.6000                 *.*                    LISTEN
udp4       0      0 192.168.0.105.514      *.*                    
udp4       0      0 192.168.0.104.514      *.*                    
udp4       0      0 192.168.0.106.514      *.*                    
udp4       0      0 *.514                  *.*                    
udp6       0      0 *.514                  *.*

Here is a xauth list from from the freebsd

Dell/unix:0  MIT-MAGIC-COOKIE-1  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Dell/unix:10  MIT-MAGIC-COOKIE-1  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

from the openbsd

localhost.Barbar:10  MIT-MAGIC-COOKIE-1  ZZZZZZZZZZZZZZZZZZZZZZZZZZZ
localhost:10  MIT-MAGIC-COOKIE-1  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Fujutsu.Barbar/unix:11  MIT-MAGIC-COOKIE-1  ZZZZZZZZZZZZZZZZZZZZZZZZZZ
Fujutsu.Barbar/unix:12  MIT-MAGIC-COOKIE-1  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Fujutsu.Barbar/unix:0  MIT-MAGIC-COOKIE-1  ZZZZZZZZZZZZZZZZZZZZZZZZZZZ
localhost.Barbar:0  MIT-MAGIC-COOKIE-1  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
localhost:0  MIT-MAGIC-COOKIE-1  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Fujutsu.Barbar/unix:10  MIT-MAGIC-COOKIE-1  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

and from the jail 192.168.0.105

mywww/unix:11  MIT-MAGIC-COOKIE-1  YYYYYYYYYYYYYYYYYYYYYYYYYYY
mywww/unix:10  MIT-MAGIC-COOKIE-1  YYYYYYYYYYYYYYYYYYYYYYYYYYY

A possible problem is that in /var/log/messages on the jails I have

Dec 23 10:27:29 mywww syslogd: kernel boot file is /boot/kernel/kernel
Dec 23 10:27:30 mywww sm-mta[1488]: My unqualified host name (mywww) unknown; sleeping for retry
Dec 23 10:28:30 mywww sm-mta[1488]: unable to qualify my own domain name (mywww) -- using short name
Dec 23 10:28:30 mywww sm-msp-queue[1528]: My unqualified host name (mywww) unknown; sleeping for retry
Dec 23 10:29:30 mywww sm-msp-queue[1528]: unable to qualify my own domain name (mywww) -- using short name

I have specified itself in it s /etc/hosts.