Cannot run X over ssh

[Vahis]

I _can_ and always have run X stuff over ssh on my 11.2 installation.

I maintain a machine remotely for a friend, have brought it from 11.3
to 11.4 remotely long ago.
At some point in the early days of 11.4 I _did_ run also X stuff there.

Otherwise the machine is just fine but now I just can't do X anymore.
I don't know for how long cos it's rare to need to.

I hadn't done this at home for a long time either so I started testing.

Same result, no can do. Not on _any_ 11.4 or above.
I get these messages:

All 64 bit machines (11.4, 11.4 Tumbleweed and 12.1):

$ssh -X
$ xclock
connect /tmp/.X11-unix/X0: No such file or directory
connect /tmp/.X11-unix/X0: No such file or directory
connect /tmp/.X11-unix/X0: No such file or directory
connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0

11.4 Tumbleweed 32 bit, 2 of them:
:~> xclock
Error: Can't open display:

All machines have it though:

$ ls /tmp/.X11-unix/X0
/tmp/.X11-unix/X0

$ file /tmp/.X11-unix/X0
/tmp/.X11-unix/X0: socket

_Except_ 11.2 which I _can_ connect to, doen't have it:

$ ls /tmp/.X11-unix/X0
ls: cannot access /tmp/.X11-unix/X0: No such file or directory

So something has changed obviously.
What needs to be changed accordingly?
This socket lives in /tmp so maybe someone creates it by itself but how?

So far everything is like default I haven't changed anythig..

Vahis
--
http://waxborg.servepics.com
openSUSE 11.2 (x86_64) 2.6.31.14-0.8-default "Evergreen" main host
openSUSE 12.1 Milestone 5 (x86_64) 3.1.0-rc6-2-desktop in VBox
openSUSE 11.4 (i586) 3.0.4-43-desktop "Tumbleweed" in EeePC 900

[Vahis]

On 2011-09-29, houghi <hou...@houghi.org.invalid> wrote:

> Vahis wrote:
>> So something has changed obviously.
>> What needs to be changed accordingly?
>

> Check /etc/ssh/sshd_config.

I have. No difference in working and not-working machines. All the same.
>
> Probably X11Forwarding is the issue.

Somehow it is but it's enabled everywhere.
The config files are the same.

The diffence I see here is that 11.2 doesn't have this socket
/tmp/.X11-unix/X0 at all.

The newer ones have it but they say they don't.

I then also removed it.
Then went to init 3.
Then went to init 5

It was back.
So it gets created when X starts.
It's owned by root, others can read and write.
It's also executable.>

Am I the only one having this issue?
I have 8 machines 64 and 32 bit, 5 real and 3 imaginary hardware.
One works, 11.2.

Nobody else has this?

Vahis
--
http://waxborg.servepics.com
openSUSE 11.2 (x86_64) 2.6.31.14-0.8-default "Evergreen" main host

openSUSE 12.1 Beta 1 (x86_64) 3.1.0-rc6-2-desktop in VBox

[Vahis]

On 2011-09-29, Vahis <wax...@gmail.com.invalid> wrote:
> I _can_ and always have run X stuff over ssh on my 11.2 installation.
>
> I maintain a machine remotely for a friend, have brought it from 11.3
> to 11.4 remotely long ago.
> At some point in the early days of 11.4 I _did_ run also X stuff there.
>
> Otherwise the machine is just fine but now I just can't do X anymore.
> I don't know for how long cos it's rare to need to.
>

> $ssh -X
> $ xclock
> connect /tmp/.X11-unix/X0: No such file or directory
> connect /tmp/.X11-unix/X0: No such file or directory
> connect /tmp/.X11-unix/X0: No such file or directory
> connect /tmp/.X11-unix/X0: No such file or directory
> Error: Can't open display: localhost:10.0

Solution On the client (local) machine:

xhost +localhost

Then ssh -X remotemachine

Works :)

Vahis
--
http://waxborg.servepics.com
openSUSE 11.2 (x86_64) 2.6.31.14-0.8-default "Evergreen" main host

openSUSE 12.1 Beta 1 (x86_64) 3.1.0-rc6-2-desktop in VBox

[J G Miller]

On Thursday, September 29th, 2011 at 09:15:34h +0000, Vahis wrote:

> xhost +localhost

Does this work which results in local file socket connections being allowed,
unlike the above which allows, potentially less secure, inet conections ?

> xhost +local:

"non-network local connections being added to access control list"

[Vahis]

I don't know.

I wonder why I could connect to _a_ host but not to _another_.
I removed the socket, restarted X and it was created again,
but still, I could connct to a host but not to another.

Then I commanded xhost +localhost and I could connect to all machines.

I removed the socket again and I couldn't connect anywhere.

I restarted X and again, the socket got created I can connect everywhere.

It all went like this:

First 11.2 -> Nowhere
Still, Everywhere -> 11.2 OK.

Anywhere else -> anywhere else No go.

All clients connect everywhere after they get first xhost +localhost.

Normal ssh has worked all the time everywhere, just X not.

Conclusion:

If you can connect over ssh normally but not X
run on the client 'xhost +localhost'

Now at least everything seems to be as it should.
I have this on every machine when I command locally::

$ xhost
access control enabled, only authorized clients can connect

Something was messed up, I still don't quite know what.

Now I'm cool. I think.

[J G Miller]

On Thu, 29 Sep 2011 12:04:21 +0000, Vahis wrote:

> I don't know.

So please could you try it?

xhost -localhost

xhost +local:

ssh -X my_remote_host

Thank you.

> $ xhost
> access control enabled, only authorized clients can connect

If there are no further lines of output, the that is the normal
secure state, for when *nobody* is allowed to connect, be it
via local socket or inet.

[Vahis]

On 2011-09-29, J G Miller <mil...@yoyo.ORG> wrote:

> On Thu, 29 Sep 2011 12:04:21 +0000, Vahis wrote:
>
>> I don't know.
>
> So please could you try it?
>
> xhost -localhost

$ xhost -localhost
localhost being removed from access control list
>
> xhost +local:

xhost +local
xhost: bad hostname "local"
>
> ssh -X my_remote_host

Works.

All in all, this is quite strange.
In the meantime I'm still in trouble with at least one machine (one
seems to be down, in another town)

A 32 bit 11.4 Tumbleweed in LAN.
Nothing helps...

>
>> $ xhost
>> access control enabled, only authorized clients can connect
>
> If there are no further lines of output, the that is the normal
> secure state, for when *nobody* is allowed to connect, be it
> via local socket or inet.

But I can connect, no problems.
Except one machine that I just found out.

[J G Miller]

On Thursday, September 29th, 2011 at 13:28:02h +0000, Vahis wrote:

> On 2011-09-29, J G Miller <mil...@yoyo.ORG> wrote:
>> On Thu, 29 Sep 2011 12:04:21 +0000, Vahis wrote:

>> So please could you try it?
>>
>> xhost -localhost
>
> $ xhost -localhost
> localhost being removed from access control list
>>
>> xhost +local:
>
> xhost +local
> xhost: bad hostname "local"

local is NOT a hostname, it is a family type,
that is why there is a colon after it.

xhost +local:
*^*

> Works.

So that means that no remote access is permitted which is
the default state.

> But I can connect, no problems.

Because the originating connection is already authorized,
because if it were not, you would not have an Xsession
running.

[Vahis]

On 2011-09-29, Vahis <wax...@gmail.com.invalid> wrote:

There's one more detail:
On one machine I get

ssh -X waxborg
Warning: No xauth data; using fake authentication data for X11
forwarding.

Works fine though...

[Vahis]

On 2011-09-29, J G Miller <mil...@yoyo.ORG> wrote:
> On Thursday, September 29th, 2011 at 13:28:02h +0000, Vahis wrote:
>
>> On 2011-09-29, J G Miller <mil...@yoyo.ORG> wrote:
>>> On Thu, 29 Sep 2011 12:04:21 +0000, Vahis wrote:
>
>>> So please could you try it?
>>>
>>> xhost -localhost
>>
>> $ xhost -localhost
>> localhost being removed from access control list
>>>
>>> xhost +local:
>>
>> xhost +local
>> xhost: bad hostname "local"
>
> local is NOT a hostname, it is a family type,
> that is why there is a colon after it.
>
> xhost +local:
> *^*

It's not there in the command.
It's just there at the end of the line of that post.

>> Works.
>
> So that means that no remote access is permitted which is
> the default state.
>
>> But I can connect, no problems.
>
> Because the originating connection is already authorized,
> because if it were not, you would not have an Xsession
> running.

I can understand that.
But I'm puzzled with How exctly the authorization takes place.

On a troublesome machine now I get, when trying to run xeyes or
whatever on a remote machine from it:
'Error: Can't open display:

When I run there 'xhost' I get:
access enabled, only authorized clients can connect.

So where and how is this authorization controlled.

I'm getting nowhere when sometimes something works and sometimes not.
Or rather on some machines works, others not.

I'm doing this wrong, I'm sure, but how is it supposed to be done?

Why is it that one out of eight stays in a non-working state?
And probably also the only one I really need this for,
which is not here and not running at all right now..

[Vahis]

On 2011-09-29, J G Miller <mil...@yoyo.ORG> wrote:
> On Thursday, September 29th, 2011 at 13:28:02h +0000, Vahis wrote:
>
>> On 2011-09-29, J G Miller <mil...@yoyo.ORG> wrote:
>>> On Thu, 29 Sep 2011 12:04:21 +0000, Vahis wrote:
>
>>> So please could you try it?
>>>
>>> xhost -localhost
>>
>> $ xhost -localhost
>> localhost being removed from access control list
>>>
>>> xhost +local:
>>
>> xhost +local
>> xhost: bad hostname "local"
>
> local is NOT a hostname, it is a family type,
> that is why there is a colon after it.
>
> xhost +local:
> *^*

xhost +local:
non-network local connections being added to access control list

>> Works.
>
> So that means that no remote access is permitted which is
> the default state.
>
>> But I can connect, no problems.
>
> Because the originating connection is already authorized,
> because if it were not, you would not have an Xsession
> running.

I can understand that.
But I'm puzzled with How exctly the authorization takes place.

On a troublesome machine now I get, when trying to run xeyes or
whatever on a remote machine from it:
'Error: Can't open display:

When I run there 'xhost' I get:
access enabled, only authorized clients can connect.

So where and how is this authorization controlled.

I'm getting nowhere when sometimes something works and sometimes not.
Or rather on some machines works, others not.

I'm doing this wrong, I'm sure, but how is it supposed to be done?

Why is it that one out of eight stays in a non-working state?
And probably also the only one I really need this for,
which is not here and not running at all right now..

[Vahis]

On 2011-09-29, houghi <hou...@houghi.org.invalid> wrote:
> Vahis wrote:

>> I can understand that.
>> But I'm puzzled with How exctly the authorization takes place.
>>
>> On a troublesome machine now I get, when trying to run xeyes or
>> whatever on a remote machine from it:
>> 'Error: Can't open display:
>>
>> When I run there 'xhost' I get:
>> access enabled, only authorized clients can connect.
>

> I get this on machines where it works.

So do I. But one does not work.

>
>> So where and how is this authorization controlled.
>>
>> I'm getting nowhere when sometimes something works and sometimes not.
>> Or rather on some machines works, others not.
>

> YaST, Security and Users, Security Center and Hardening (Will be called
> different in other versions) and at the pre-defined set it all to "Home
> workstation" on first the server and see if this changes anything. If it
> does, you can star playing around.
>
> Perhaps a silly question, but as the server is remote, are you sure that
> X is installed on it? Also: See that the firewall is disabled for a
> single test (and enable it again after the test)

This deems not to be a firewall thing at all.
It's about xserver only.
>
> I did a grep -R on /etc/* for xhost but found nothing, except vbox
> stuff.

There isn't any.
I have been trying to understand man xhost.

[Vahis]

On 2011-09-29, houghi <hou...@houghi.org.invalid> wrote:

> houghi wrote:
>> Perhaps a silly question, but as the server is remote, are you sure that
>> X is installed on it? Also: See that the firewall is disabled for a
>> single test (and enable it again after the test)
>

> As an afterthought. Perhaps the reason why it works with most is because
> they are in the same IP range of domestic violence aka 193.168.* * or
> 10.*.*.* and standard configuration will allow it. And the other one is
> not and thus does not allow it.

No. Nothing to do with that.
All the machines have their LAN addresses from 196.168 series and also
external ones. If one address works, the other one does.

And if one doesn't the other won't either.

I'm so far now that all the machines, except one, that I can get hold of
right now do everything both ways.

One can connect everywhere else but nobody can connect to it.

Or rather, connections are fine, just X can't open a display on that
particular one.

That is a special one. When I connect _from_ it, everything works, I can
run X-apps on other machines and they display on the host I connected to.

Which is correct.

If I connect _to_ it and export alsoo the display there I can run X-apps
and they show up _there_.

Which is again correct.

But if I connect _to_ it and want to see the app _here_ I 'can't open the
display'

I've made progress, though, the ratio has changed from i of 8 to 7 of 8.

And then there's the one I haven't reached yet.
The one that failed and all this crap started in the first place.

The one I need this whole thing for.

[J G Miller]

On Thursday, September 29th, 2011 at 14:08:29h +0000, Vahis wrote:

> But I'm puzzled with How exctly the authorization takes place.

The normal implementation of the Xorg X server is with an MIT magic
cookie file. When you login using the graphical display manager
a file is created in your ${HOME} directory

.Xauthority

This is user based.

From <http://download.oracle.COM/docs/cd/E19683-01/806-7612/network-15/index.html>

QUOTE

MIT-MAGIC-COOKIE-1

The MIT-MAGIC-COOKIE-1 authorization protocol was developed by the Massachusetts Institute of Technology.

At server startup, a magic cookie is created for the server and the user who started the system.

On every connection attempt, the user's client sends the magic cookie to the server as part of the
connection packet. This magic cookie is compared with the servers' magic cookie.

The connection is allowed if the magic cookies match, or denied if they do not match.

UNQUOTE

> So where and how is this authorization controlled.

Access by other hosts (including other users on the same machine)
to your DISPLAY on the Xserver currently running
on your machine is controlled with the use of xhost.

xhost +local:

allows access to the DISPLAY via the named socket
so that network connections even from the local host
are denied.

xhost +local

allows access from what is usually the name for the
local non networked connected lo interface 127.0.0.1
so allows network access from other same host users

xhost +

allows absolutely anybody on any network machine to connect

xost -

turns off remote network access.

> I'm getting nowhere when sometimes something works and sometimes not. Or
> rather on some machines works, others not.

Is that a possibly maybe or maybe not, or only sometimes but never always?

> I'm doing this wrong, I'm sure, but how is it supposed to be done?

Could be that your problem is your .Xauthority file has not been
created or has been deleted.

Without any definite information analysis of the problem is
probably always impossible, or sometimes maybe sometimes not.

[Vahis]

On 2011-09-29, Vahis <wax...@gmail.com.invalid> wrote:

> I _can_ and always have run X stuff over ssh on my 11.2 installation.
>
> I maintain a machine remotely for a friend, have brought it from 11.3
> to 11.4 remotely long ago.
> At some point in the early days of 11.4 I _did_ run also X stuff there.
>
> Otherwise the machine is just fine but now I just can't do X anymore.
> I don't know for how long cos it's rare to need to.
>
> I hadn't done this at home for a long time either so I started testing.

At this point all "good" machines connect back and forth flawlessly.
They run X apps on each other, even through each other.

One of the "good" gives this when the connection is made:

:~> ssh -X waxborg

Warning: No xauth data; using fake authentication data for X11
forwarding.

But it connects fine and runs X apps on the host.

The troublesome machine conncts to other machines and runs their X apps
fine. You can connect to it but X apps give

:~> xclock
Error: Can't open display:

If you connect to it and export the client's display it will display it
fine.

On that troublesome machine I have tried:

Removing /tmp/.X11-unix/X0

Then recreating it by starting X from scratch
This brings nothing new.

Creating new test user
This brings nothing new.

:~> xclock
Error: Can't open display:

The message there is not very informative.

Except that it says display:
colon | there

Is this a hint of some kind maybe?

Vahis
--
http://waxborg.servepics.com
openSUSE 11.2 (x86_64) 2.6.31.14-0.8-default "Evergreen" main host

openSUSE 12.1 Beta 1 (x86_64) 3.1.0-rc6-2-desktop in VBox

[Vahis]

On 2011-09-30, houghi <hou...@houghi.org.invalid> wrote:

> J G Miller wrote:
>>> I'm getting nowhere when sometimes something works and sometimes not. Or
>>> rather on some machines works, others not.
>>
>> Is that a possibly maybe or maybe not, or only sometimes but never always?
>>
>>> I'm doing this wrong, I'm sure, but how is it supposed to be done?
>>
>> Could be that your problem is your .Xauthority file has not been
>> created or has been deleted.
>

I conect first normally ssh -X or ssh -Y, same results:

tester@lamborghini:~> xclock

Error: Can't open display:

tester@lamborghini:~>

Then after removing .Xauthority:

tester@lamborghini:~> l .Xauthority
ls: cannot access .Xauthority: No such file or directory

tester@lamborghini:~> xclock

Error: Can't open display:

tester@lamborghini:~>

init 3
init 5

tester@lamborghini:~> l .Xauthority
-rw------- 1 mcman users 203 30.9. 09:45 .Xauthority

tester@lamborghini:~> xclock

Error: Can't open display:

tester@lamborghini:~>

If I do all the above sitting _at_ the client in _local_ terminal there
xeyes, fine
xclock, fine

ssh -X localhost
ssh -Y localhost
xeyes

Error: Can't open display:

So I go at the client
ssh -X lambo
export DISPLAY=:0.0
tester@lamborghini:~> xclock

The clock is there, on lambo's screen. Or the eyes.

I'm too old for this shit. And very lonely, too.

I didn't quite think so but I'm apparently better off with this:
http://waxborg.servepics.com/wpg2?g2_itemId=5752

[J G Miller]

On Friday, September 30th, 2011 at 07:05:01h +0000, Vahis wrote:

> I conect first normally ssh -X or ssh -Y, same results:
>
> tester@lamborghini:~> xclock
> Error: Can't open display:
> tester@lamborghini:~>
>
> Then after removing .Xauthority:
>
> tester@lamborghini:~> l .Xauthority
> ls: cannot access .Xauthority: No such file or directory
>
> tester@lamborghini:~> xclock
> Error: Can't open display:
> tester@lamborghini:~>

Okay, thank you for the details

Immediately after ssh -X lamborghini, on lamborghini
do this

echo "->${DISPLAY}<-"

Do that also on a "working" connection and see what the
difference is.

The output should be something like

->localhost:10.0<-

The number that appears there is determined by the
setting in the sshd config file

X11DisplayOffset 10

What value do you have in the sshd config file
on the problem machine?

I trust you are NOT doing this --

machine a -> slogin -X machine b -> slogin -X lamborghini

For that to work X11 forwarding must be set on machine b
in the sshd file.

[Vahis]

On 2011-09-30, Vahis <wax...@gmail.com.invalid> wrote:
> On 2011-09-29, Vahis <wax...@gmail.com.invalid> wrote:

>> Otherwise the machine is just fine but now I just can't do X anymore.

>> I hadn't done this at home for a long time either so I started testing.

If you connect _to_ it from another machine in order to show
locally on the machine you connect _from_

ssh -X lamborghini
Last login: Fri Sep 30 12:43:32 2011 from 192.168.0.92
tester@lamborghini:~> xclock

Error: Can't open display:

tester@lamborghini:~>

So you can't run stuff there and show it here.

But if you then export your local display

tester@lamborghini:~> export DISPLAY=:0.0
tester@lamborghini:~> xclock

Now it shows fine on lamborghini's screen

So you can run stuff and show it there.

If you sit at it, connect _from_ it to a remote machine,
You can do your stuff.

If you sit at it and then
export the display
then xstuff runs fine and diplays on that remote machine.

tester@lamborghini:~> export DISPLAY=:0.0
tester@lamborghini:~> xclock

Shows fine on lamborghini's screen.

_From_ it works fine.
_To_ it works one way.

Go figure

[Vahis]

On 2011-09-30, J G Miller <mil...@yoyo.ORG> wrote:

> Okay, thank you for the details
>
> Immediately after ssh -X lamborghini, on lamborghini
> do this
>
> echo "->${DISPLAY}<-"

tester@lamborghini:~> echo "->${DISPLAY}<-"
-><-

Nothing, no wonder it can't be opened.

>
> Do that also on a "working" connection and see what the
> difference is.

[tester@vb121 ~]$ echo "->${DISPLAY}<-"

->localhost:10.0<-
>
> The output should be something like
>
> ->localhost:10.0<-
>
> The number that appears there is determined by the
> setting in the sshd config file
>
> X11DisplayOffset 10
>
> What value do you have in the sshd config file
> on the problem machine?

They all have the same, even the bad one:

#X11DisplayOffset 10

>
> I trust you are NOT doing this --
>
> machine a -> slogin -X machine b -> slogin -X lamborghini

I done that, too. Works fine. On other machines, but if there this
lamborghini somewhere in between it doesn't work.

> For that to work X11 forwarding must be set on machine b
> in the sshd file.

[Vahis]

On 2011-09-30, Vahis <wax...@gmail.com.invalid> wrote:

> On 2011-09-29, Vahis <wax...@gmail.com.invalid> wrote:

>> Otherwise the machine is just fine but now I just can't do X anymore.

>> I hadn't done this at home for a long time either so I started testing.

If you connect _to_ it from another machine in order to show
locally on the machine you connect _from_

ssh -X lamborghini
Last login: Fri Sep 30 12:43:32 2011 from 192.168.0.92

tester@lamborghini:~> xclock

Error: Can't open display:

tester@lamborghini:~>

So you can't run stuff there and show it here.

But if you then export your local display

tester@lamborghini:~> export DISPLAY=:0.0
tester@lamborghini:~> xclock

Now it shows fine on lamborghini's screen

So you can run stuff and show it there.

If you sit at it, connect _from_ it to a remote machine,
You can do your stuff.

If you sit at it and then
export the display
then xstuff runs fine and diplays on that remote machine.

tester@lamborghini:~> export DISPLAY=:0.0
tester@lamborghini:~> xclock

_From_ it works fine.
_To_ it works one way.

Go figure

[J G Miller]

On Friday, September 30th, 2011 at 10:31:40h +0000, Vahis wrote:

> tester@lamborghini:~> echo "->${DISPLAY}<-" -><-
>
> Nothing, no wonder it can't be opened.

Thanks for doing the tests.

Thus DISPLAY is not set when you login to lamborghini.

Which distribution/version do you have on lamborghini
compare to the other machines?

Is the sshd config file on that machine identical to
the other machines?

The other possibility is that your shell initialization
files on lamborghini are wiping DISPLAY. For bash,
this could be anything from /etc/profile to your
$HOME/.bashrc.

IF you manually do

export DISPLAY="localhost:10.0"

on lamborghini immediately after slogin -X lamborghini
and try xeyes, does that work?

IF that works then the authentication is okay,
and the only question is why does DISPLAY not have
a value.

[Vahis]

On 2011-09-30, J G Miller <mil...@yoyo.ORG> wrote:

> On Friday, September 30th, 2011 at 10:31:40h +0000, Vahis wrote:
>
>> tester@lamborghini:~> echo "->${DISPLAY}<-" -><-
>>
>> Nothing, no wonder it can't be opened.
>
> Thanks for doing the tests.
>
> Thus DISPLAY is not set when you login to lamborghini.
>
> Which distribution/version do you have on lamborghini
> compare to the other machines?

The one we're talking about now is 11.4 Tumbleweed 32 bit, HW.

I'm happy I happened to have one at home with same peoblem
as the original troublemaker (remote) 11.4 32 bit, HW.

The good ones are
1x 11.2, 64 bit, HW,
2x 11.4, 32 bit, HW
1x 11.4, 64 bit, virtual
1x 11.4 Tumbleweed, 64 bit, virtual
1x 12.1, 84 bit, virtual

>
> Is the sshd config file on that machine identical to
> the other machines?

Should be, done nothing about it.
I can copy it from a good machine and try.

>
> The other possibility is that your shell initialization
> files on lamborghini are wiping DISPLAY. For bash,
> this could be anything from /etc/profile to your
> $HOME/.bashrc.

I have copied .bashrc from a good machine.
They were supposed to be identical anyways.

>
> IF you manually do
>
> export DISPLAY="localhost:10.0"
>
> on lamborghini immediately after slogin -X lamborghini
> and try xeyes, does that work?

[tester ~]$ ssh -X lamborghini
Last login: Fri Sep 30 13:22:24 2011 from 192.168.0.99
Have a lot of fun...
tester@lamborghini:~> export DISPLAY="localhost:10.0"
tester@lamborghini:~> xeyes
Error: Can't open display: localhost:10.0
tester@lamborghini:~>

>
> IF that works then the authentication is okay,
> and the only question is why does DISPLAY not have
> a value.

This is ocally on lamborhini:
tester@lamborghini:¨>
ssh -X localhost
echo $DISPLAY

tester@lamborghini:¨>

Just an empty line there.

[Vahis]

On 2011-09-30, J G Miller <mil...@yoyo.ORG> wrote:

> On Friday, September 30th, 2011 at 10:31:40h +0000, Vahis wrote:
>
>> tester@lamborghini:~> echo "->${DISPLAY}<-" -><-
>>
>> Nothing, no wonder it can't be opened.
>
> Thanks for doing the tests.
>
> Thus DISPLAY is not set when you login to lamborghini.
>
> Which distribution/version do you have on lamborghini
> compare to the other machines?

The one we're talking about now is 11.4 Tumbleweed 32 bit, HW.

I'm happy I happened to have one at home with same problem

as the original troublemaker (remote) 11.4 32 bit, HW.

The good ones are
1x 11.2, 64 bit, HW,
2x 11.4, 32 bit, HW
1x 11.4, 64 bit, virtual
1x 11.4 Tumbleweed, 64 bit, virtual

1x 12.1, 64 bit, virtual

>
> Is the sshd config file on that machine identical to
> the other machines?

Should be, done nothing about it.
I can copy it from a good machine and try.
>

> The other possibility is that your shell initialization
> files on lamborghini are wiping DISPLAY. For bash,
> this could be anything from /etc/profile to your
> $HOME/.bashrc.

I have copied .bashrc from a good machine.
They were supposed to be identical anyways.
>

> IF you manually do
>
> export DISPLAY="localhost:10.0"
>
> on lamborghini immediately after slogin -X lamborghini
> and try xeyes, does that work?

[tester ~]$ ssh -X lamborghini
Last login: Fri Sep 30 13:22:24 2011 from 192.168.0.99
Have a lot of fun...
tester@lamborghini:~> export DISPLAY="localhost:10.0"

tester@lamborghini:~> xeyes
Error: Can't open display: localhost:10.0
tester@lamborghini:~>

>
> IF that works then the authentication is okay,
> and the only question is why does DISPLAY not have
> a value.

This is ocally on lamborhini:
tester@lamborghini:¨>
ssh -X localhost
echo $DISPLAY

tester@lamborghini:¨>

Just an empty line there.

[J G Miller]

On Friday, September 30th, 2011 at 12:21:59h +0000, Vahis wrote:

> The one we're talking about now is 11.4 Tumbleweed 32 bit, HW.

Is it the case then that the only machines on which slogin -X
fails to set the DISPLAY variable on the remote machine are
machines running 11.4 Tumbleweed ?

> Should be, done nothing about it.

You should copy the sshd config file over to say /tmp on
a good machine and compare it to the sshd config file on
a good machine.

fldiff is extremely helpful in comparing files,
so install that if you do not already have it available.

fldiff file1 file2

> I have copied .bashrc from a good machine. They were supposed to be
> identical anyways.

I do not think we need to worry about this since it is now
becoming clearer where the problem is originating -- either
the sshd config or a bug in the sshd version on lamborghini.

> tester@lamborghini:~> export DISPLAY="localhost:10.0"
> tester@lamborghini:~> xeyes
> Error: Can't open display: localhost:10.0

It shows that X11 authentication has not occurred and it is
not just a setting of the the DISPLAY environmental variable
problem.

[Vahis]

On 2011-09-30, J G Miller <mil...@yoyo.ORG> wrote:

> On Friday, September 30th, 2011 at 12:21:59h +0000, Vahis wrote:
>
>> The one we're talking about now is 11.4 Tumbleweed 32 bit, HW.
>
> Is it the case then that the only machines on which slogin -X
> fails to set the DISPLAY variable on the remote machine are
> machines running 11.4 Tumbleweed ?

No. One is.

>
>> Should be, done nothing about it.
>
> You should copy the sshd config file over to say /tmp on
> a good machine and compare it to the sshd config file on
> a good machine.

I put the file from a good machine to a bad one.
Looks like it works now.

>
> fldiff is extremely helpful in comparing files,
> so install that if you do not already have it available.
>
> fldiff file1 file2

I'll compare those files soon.

>
> I do not think we need to worry about this since it is now
> becoming clearer where the problem is originating -- either
> the sshd config or a bug in the sshd version on lamborghini.

> It shows that X11 authentication has not occurred and it is
> not just a setting of the the DISPLAY environmental variable
> problem.