It is very common that UNIX / Linux systems that are accessed by SSH do not allow direct access with root. It must be authenticated as a normal user and then, if access is needed root, it is used suto get a shell root. On systems with OpenSSH, in the file /etc/sshd/sshd_configwe will find the parameter PermitRootLogin, which is “no” in many systems. Among the advantages of not allowing direct access rootis that the user – in theory – will not go rootthrough unless he needs it and it is registered which users are / have been in the system.

But this configuration generates problems with the forwarding of X11 windows through SSH. For example, with HP-UX and Solaris systems (later we will see what happens with Linux), when you access by SSH with a user forwarding the windows X11 and then you do a su, we lose the tunnel of X11:

$ Ssh -X user test @ solx86
Password:
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$
$ Echo $ DISPLAY
Localhost: 10.0
$
$ / Usr / openwin / bin / xclock
$
$ Su -
Password:
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
#
# Echo $ DISPLAY
#
# / Usr / openwin / bin / xclock
Error: Can not open display:

If we put the variable on hand $DISPLAY, the error will change from being unable to access the display to which it is not authorized to use the display :

# DISPLAY = localhost: 10.0
# Export DISPLAY
# 
# / Usr / openwin / bin / xclock
X11 connection rejected because of wrong authentication.
X connection to localhost: 10.0 broken (explicit kill or server shutdown).

A solution, taking advantage of the fact that it rootcan access the files of all users, is to modify the variable $XAUTHORITYto use the file. Xauthorityof the user with which we entered and not that of root:

# XAUTHORITY = / export / home / testUser / .Xauthority
# Export XAUTHORITY
#
# / Usr / openwin / bin / xclock

When entering a SSH system with the X11 forwarding option enabled, the SSH server adds a MIT-MAGIC-COOKIE-1 to the file $HOME/.Xauthorityso that only that user (and not others that are connected to the machine and try to use the same $ DISPLAY) can use your SSH tunnel to forward X11 windows. If the user rootuses the same magic cookie, then he can enter without problems.

Another option to not completely replace the one .Xauthorityof roothappens to list the magic cookies available in the one .Xauthorityof the user:

$ / Usr / openwin / bin / xauth list
Clientessh: 0 MIT-MAGIC-COOKIE-1 e712f99f148d5bf00e5df9f345635434
Sistemavncserver: 1 MIT-MAGIC-COOKIE-1 d30c3ab6ca017837260ff6221fd80da7
Solx86 / unix: 10 MIT-MAGIC-COOKIE-1 1d9076a2068a5e79d1259bea382cec2d

We extract in binary format only the entry that interests us:

$ / Usr / openwin / bin / xauth extract .Xauthority_solx86 solx86 / unix: 10

And now root, we join the entry to the existing and we will be able to access the X server:

$ Su -
Password:
Sun Microsystems Inc. SunOS 5.10 Generic july 2005
# DISPLAY = localhost: 10.0
# Export DISPLAY
#
# / Usr / openwin / bin / xauth merge /export/home/test/.Xauthority_solx86
#
# / Usr / openwin / bin / xauth list
Solx86 / unix: 10 MIT-MAGIC-COOKIE-1 1d9076a2068a5e79d1259bea382cec2d
#
# / Usr / openwin / bin / xclock

And more choice would be, after listing the existing entries, simply add the magic cookie to hand on .Xauthorityto root:

# / Usr / openwin / bin / xauth add solx86 / unix: 10 MIT-MAGIC-COOKIE-1 1d9076a2068a5e79d1259bea382cec2d
#
# / Usr / openwin / bin / xclock

We said that in Linux we do not have this problem. When passing to us root, the variable $DISPLAYis preserved and we do not need to add the magic cookie so that the X11 windows forwarding simply continues working:

# Ssh -X userpruebap @ rh5x64
Userpruebap @ rh5x64's password:
$
$ Xclock
$
$ Echo $ DISPLAY
Localhost: 10.0
$
$ Su -
Password:
[Root @ rh5x64 ~] # echo $ DISPLAY
Localhost: 10.0

This magic of Linux systems is provided by the PAM module pam_xauth:

The pam_xauth PAM module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, When xauth is enabled and a user use the your (1) command to assume another user’s privileges, That user is no longer able to access the Original user’s X display Because the new user does not Have the key needed to access the display . Pam_xauth solves the problem by forwarding the key from the user running to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is down.

Thus, in the file /etc/pam.d/su, we will typically find a line like this:

Session optional pam_xauth.so

The module stores the necessary magic cookies in different files $HOME/.xauth??????:

# Xauth -f .xauthrBGj8r list
Rh5x64 / unix: 10 MIT-MAGIC-COOKIE-1 aaceeca9bf499b5c85aba64a3ae42bd0

Which, although they are normally eliminated on their own, sometimes remain abandoned. So in Google we can find quite a few cases of people asking what these .xauthXXXXX files are and why they have many.

And finally, a mention of the Remote X Apps mini-HOWTO, where we can review the basics of how to run X11 applications from one system on the X server of another UNIX / Linux system.

Share your thought with us.

Author

Am a tech geek.. Do you wanna know more about me..? My contents will do tell you.

Pin It