7

I have a Red Hat 7.3 server running XVnc. On a Windows 10 desktop I have Putty and Xming installed. Putty is configured for X11 forwarding. When I SSH in as my standard/non-privileged user and launch an X application, it displays on my Windows 10 desktop without issue.

Now within same session, if I su to a more privileged account and try to run an X application, it fails with "error: can't open display".

In my standard user session if I echo $DISPLAY it is automatically set for me as "IP_ADDRESS:10.0". Under my su session, $DISPLAY is null. I tried exporting the DISPLAY variable to the same value but it now a different error appears: "PuTTY X11 proxy: Unsupported authorization protocol Error: Can't open display:server_IP:10.0".

How can I configure the X11 forwarding to work under the context of the other user?

Improve this question
2

3 Answers 3

Reset to default
15

The below steps should fix the issue for you.

Say it's working for user1 and you want to use it for user2

For user1:

$ xauth list $DISPLAY
<output1>
$ echo $DISPLAY
<outoput2>

Switch to other user , i.e user2

$ xauth add <output1> 
$ export DISPLAY=<output2>

Try:

$ xclock
Improve this answer
2
  • This works but it tedious. It would be nice to add a simple alias command that can do most of this work automatically somehow, at least not require copying and pasting. Wishful thinking on my part, perhaps.
    – Leonid
    Commented Feb 17, 2023 at 17:08
  • xauth: timeout in locking authority file when doing: xauth add
    – Slava Fomin II
    Commented Apr 2 at 10:04
4

That's because the the X11 display connection belongs to the user with which you log in via SSH. X11Forwarding mechanism does not allow anyone else to use the display.

Fortunately, there's a workaround. After using su and become the othe user, issue this command:

xauth add $(xauth -f ~username/.Xauthority list | tail -1)

where ~username is your original user, i.e. the user with which you connected to the server.

Obviously, this works if your new user has enough privileges to read ~username/.Xauthority (i.e. if you su to root then there are no problems, if to another user it might not work and you need to check/modify permissions).

Improve this answer
2
  • 1
    Thx! If you have no .Xauthority file for the target user and you are find with user1 security you can simply copy the auth file (for me it was from user1 to root): cp /home/user1/.Xauthority /root/
    – Vladimir T
    Commented Sep 20, 2021 at 16:17
  • This looked promising. A single simple command. The entire suggested command hangs for me, and so does this command (a sub-command of what the suggested command posted above) when run stand-alone: xauth -f ~username/.Xauthority. I assume this is some sort of permission issue. The second user is not root and I do not have admin privileges on this system, though I could submit a ticket to make a change. I am just not sure what needs to be changed. Do you? also, if I manage to solve this issue by myself, then I will leave another comment here.
    – Leonid
    Commented Feb 17, 2023 at 17:13
1

Slight change to Daniele's workaround:

xauth add $(xauth -i -f ~username/.Xauthority list | tail -1)

The -i option ignores locks; this way the xauth list command won't hang.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .