[FreeNX-kNX] Re: Problem with Nx, Fluxbox and suspended sessions

[Marco Passerini]

Hi!

I think I found the problem, and it happens because I'm using SU 
authentication:
ENABLE_SSH_AUTHENTICATION="0"
ENABLE_SU_AUTHENTICATION="1"

If I switch the configuration back to the default SSH authentication the 
problem with xauth does not appear anymore.
Using SSH authentication it generates the file with the name .Xauthority 
and it resumes sessions correctly.

Using SU authentication instead it generates the files 
.xauth*randomcode* , which do not work well with NX.


Said this, I still would like to keep using SU authentication, because 
it displays the logs in a format which allows me to easily configure 
Fail2ban to ban the IP:

e.g.:
SU authentication:
May 13 16:50:25 myhostname nxserver[13262]: (nx) Failed password for 
user=myusername from IP=*.*.*.*
(where *.*.*.* is the IP of the client to ban)

SSH authentication:
May 13 16:48:39 myhostname sshd[12486]: Failed password for myusername 
from 127.0.0.1 port 39319 ssh2

Is there some problem in the implementation of the SU_AUTHENTICATION mode?



On 05/13/2011 12:07 PM, chris at ccburton.com wrote:
> Marco Passerini<marco.passerini at csc.fi>  wrote on 13/05/2011 09:32:56:
>> Hi,
>>
>> Look at this:
> OK  ;-)
>> ### fresh session ##
>> $ echo $XAUTHORITY
>> /home/myusername/.xauth6GGIy3
> So that's your cookie file for this session . . .
>
> . . . it is named differently from the previous one, so it is probably
> a computed "random" filename, but it might relate to something else.
>
> I don't know why this is being done, or what is doing it, so you will
> need to search it out yourself, in lieu of anyone else helping.
>
>> $ ls -a | grep xauth
>> .xauth6GGIy3
>>
>> $ cat .xauth6GGIy3
>> myhostname.com/unix:10 MIT-MAGIC-COOKIE-1 **cookie**
>> localhost.localdomain:1000 MIT-MAGIC-COOKIE-1 **cookie**
>> myhostname.com/unix:1000 MIT-MAGIC-COOKIE-1 **cookie**
> Is it a text file or did you filter the output.
> What does
>          file /home/myusername/.xauth6GGIy3
> output ??
>
>> $ xauth  -f ~/.xauth6GGIy3 list
>> myhostname.com/unix:10 MIT-MAGIC-COOKIE-1 **cookie**
>> localhost.localdomain:1000 MIT-MAGIC-COOKIE-1 **cookie**
>> myhostname.com/unix:1000 MIT-MAGIC-COOKIE-1 **cookie**
>>
>> $ ls -a | grep Xauth
>> .Xauthority
>>
>> $ cat .Xauthority
>> [empty]
>>
>> $ xauth  -f ~/.Xauthority list
>> [no result]
> That isn't your cookie file . . . .
>
>>
>> ### restored session ###
>>
>> $ echo $XAUTHORITY
>> /home/myusername/.xauth6GGIy3
>>
>> $ ls -a | grep xauth
>> [no result]
> It's been cleared . . .
>
> FreeNX runs
>          xauth remove
> on its display.
>
>> $ ls -a | grep Xauth
>> .Xauthority
>>
>> $ cat .Xauthority
>> [empty]
> You do have write access to
>          ~/.Xauthority
> don't you ??
>
>> $ xauth  -f ~/.Xauthority list
>> [no result]
> This hasn't been written back out !!
>
>> $ xauth list
>> xauth: creating new authority file /home/myusername/.xauth6GGIy3
> It will say this if the file is non existent or empty.
>
> It won't actually create an empty one tho', if there isn't one.
>
>> $ ls -a | grep xauth
>> [no result]
>>
>>
>> So... apparently .Xauthority do not have any function, the only cookie
>> file used is .xauth**code**. Once I suspend the session the cookie is
>> removed and it's not generated anymore.
> Yup
>
>> I made a backup of the cookie before suspending the fresh session, and I
>> restored it once the session has been restored. Once the cookie is back
>> in place, it works! I can open new windows and everything works fine!
> Yup
>
>> I see now where the problem is... but, how could I fix it ? Does FreeNX
>> have problems with the fact that the cookie is called .xauth*code* and
>> not .Xauthority? Or is the issue somewhere else?
> FreeNX its-self uses the one in
>           .nx/C-machine-port-session-no/authority
> but
> it doesn't set
>           $XAUTHORITY
> so
> your session and apps etc. normally use the default,
> unless
> something else sets it.
> but
> FreeNX "should" write the contents of its own cookie file out to
>          ~/.Xauthority
> (and then it merges back I think, but I haven't followed it all through
> and nothing gets merged on my systems)
>
>
> I'm not quite sure what your setup or fluxbox are doing . . . .
>
> You could try a bodge overwrite of XAUTHORITY in your fluxbox
> launcher script
> but,
> my advice is (FWIW) is
> grep to find where your XAUTHORITY is computed and set
> and then
> try hard clearing it,
> eg
>          unset XAUTHORITY
>   so the default is used.
>
> Then TEST everything, because there may be other implications
>
> Let us know if you find anything out about it.
>
> cb