On Tue, Mar 09, 2010 at 10:18:09PM +0000, Chris G wrote:
I have a headless 'server' system which runs Ubuntu Server. Nearly all of the time I do maintenance, updates, etc. on the command line so it's just a matter of 'ssh server ....' to do what I need to do.
However, occasionally, it's nice to use a GUI application to do something. Until now these have always needed root on the server system and the following sequence works OK:-
chris$ ssh -X server chris@server:~$ sudo -s [sudo] password for chris: root@server:~# <run GUI program>The trouble is that when I try to do the same for a non-root user on the server system I get:-
chris$ ssh -X server chris@server:~$ sudo -s root@server:~# su www-data www-data@server$ sqlitebrowser X11 connection rejected because of wrong authentication. sqlitebrowser: cannot connect to X server localhost:12.0I have xhost allowing the following:-
chris$ xhost access control enabled, only authorized clients can connect NIS:www-data@server NIS:root@server SI:localuser:chris SI:localuser:gdm SI:localuser:rootSo why can root GUI programs display on my screen while non-root GUI programs can't? I've tried 'xhost +' to allow anyone to connect but I still get the same error. $DISPLAY is correctly carried through the various logins, I've checked that. Also www-data is the same UID on both systems though I don't really see why that would be relevant.
OK, I *could* run sqlitebrowser as root (I have tried and it works OK) but I then end up with lots of files having wrong permissions, it would be much nicer if I could run it as www-data.
Well I have solved the problem but not the above really.
I've set up so that 'chris' on my desktop can ssh to www-data on the server machine directly by putting the right bits and pieces into /var/www/.ssh. So there's still no password for www-data in /etc/shadow which keeps security reasonably good but the X authority doesn't get lost on the way in.
The reason for my problem above is that the X authority stuff gets lost when moving from root to www-data. You can sort it out by using 'xauth list' on the client and adding what it outputs to the destination account with 'xauth add' but it's messy and complicated for something that's essentially simple.