Suppose you want to brute force get yourself a connection with X...
Lets assume you are already running your commands on the server (where X runs), otherwise get that to work first and then use 'ssh -X user@server' from the client afterwards ;).
There might be several ways to run the xauth commands, for example, you might be using 'sudo', but that might lose or change environment variables. The following environment variables need to be preserved: DISPLAY and XAUTHORITY. To test if that is the case you could run 'echo $XAUTHORITY' in the same way you run your commands, but make sure you aren't expanding the environment variables before you run those commands. For example, try: sudo bash -c 'echo "$XAUTHORITY"' to see what XAUTHORITY really is after you run your sudo (if it disappears you might need to add something to your sudoers file, see elsewhere).
Eventually, run the following command as the user that you want to get access with, on the server:
xauth info
This will show the 'Authority file' that will be used (/root/.Xauthority by default, for root, or something like /home/theuser/.Xauthority). If it shows the correct .Xauthority file then you don't have to worry about the XAUTHORITY environment variable actually (actually, I wouldn't know when it wouldn't, except if you want to manipulate a non-standard place of that file).
Remove that file (if it even exists):
mv /root/.Xauthority /root/.Xauthority.bak
In the above command, replace /root/.Xauthority
with the correct XAUTHORITY file for your case of course.
Recreate it, but empty (this is needed for a lot of commands):
touch /root/.Xauthority
At this point you'll get the No protocol specified error, even if you got Invalid MIT-MAGIC-COOKIE-1 before. Find the authority file that the X server is using at the moment:
ps aux | grep Xorg
This should show something like:
root 1153 0.0 1.0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711} -background none -noreset -displayfd 17 vt7
The file name after -auth
is what you need in the next command. Run this as root:
sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list
That lists a 32 digit hexadecimal key. For example the output could be:
hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7
Use that to generate your .Xauthority file (as user who needs to login again):
xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7
replace 'c0eaf749aa252101a0f57d5087089db7' with what was returned by the list command for you. Now your .Xauthority should be size 51 bytes and you can connect to the X server (again).
PS If you start Xorg by running /usr/bin/startx
, like me; then you might see something like:
root 1652 0.0 0.0 12788 5792 ? Ss jan20 0:00 login -- carlo
carlo 1834 0.0 0.0 8140 3468 tty1 Ss jan20 0:00 \_ -bash
carlo 1887 0.0 0.0 7404 3236 tty1 S+ jan20 0:00 \_ /bin/sh /usr/bin/startx
carlo 1905 0.0 0.0 3912 828 tty1 S+ jan20 0:00 \_ xinit /home/carlo/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.WWPpq4OSlA
root 1906 1.2 0.7 25576848 235104 tty1 Sl jan20 207:56 \_ /usr/lib/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.WWPpq4OSlA
carlo 1917 0.0 0.0 143408 10884 tty1 Sl jan20 0:00 \_ startplasma-x11
And the /tmp/serverauth.WWPpq4OSlA
was deleted.
See /usr/bin/startx
script for how this works:
mcookie=`/usr/bin/mcookie`
xserverauthfile=`mktemp -p /tmp serverauth.XXXXXXXXXX`
trap "rm -f '$xserverauthfile'" HUP INT QUIT ILL TRAP KILL BUS TERM
xauth -q -f "$xserverauthfile" << EOF
add :$dummy . $mcookie
EOF
as well as
xauth -q << EOF
add $displayname . $mcookie
EOF
adding the random cookie to the users .Xauthority
file.
In this case the cookie has completely vanished thus. The only place where you can get it back from is the memory (RAM) of the Xorg process; but I am too lazy to figure out how to recover that. Just restarting X should regenerate your .Xauthority
file with a new cookie and also restart the server with that same cookie, of course.