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
# 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
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
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
# / 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
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
# 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.