It is easy enough to 'fetch' (ie draw locally) a remotely running linux application: If I ssh -Y to the remote machine and run an application, that application will surely enough pop up in my local desktop.

If , however, while I am ssh'ed in the remote machine, I su to a different user, I can not forward the X application to my local machine. It says wrong authentication.

I am not sure how to tackle this case. The echo $DISPLAY is still correct (set by the initial ssh -Y logon), but the session cookie is probably only set for the initial user that logged on ssh.

How can I overcome this difficulty and forward other X applications that are run from different users?

The reason I am not ssh'ing directly is because I don't want that user to be accessible through ssh (it is the "virtualbox" user, which is obviously an easy target for bots trying to ssh to that server)...


When you connect to a remove machine via ssh with X11 forwarding enabled, ssh on the server creates a .Xauthority file in the user's home directory. Because ssh listens for X11 on a TCP socket, anyone can connect. Because anyone can connect, we need some way of preventing just anyone from using your display. This is done with that .Xauthority file. The file contains a "cookie" which is presented to the X11 server that verifies the client should be allowed to connect.

Skipping all the details, if you copy that .Xauthority file to your target user's home directory (and give them ownership), you should be able to connect.

  • It's worth noting that even after doing this the DISPLAY variable needs to be set correctly after switching users. This can be a problem when using 'sudo' which may filter out the environment. – Chris Arguin Jul 15 '16 at 20:03
  1. ssh -Y to the remote machine as yourself.
  2. Once there, type xauth list. A list of MAGIC-COOKIE items appears. Your login session is most likely the bottom one on the list. (Check this by looking at the hostname and UNIX number code, and comparing it with the hostname you shelled from and your current localhost:## DISPLAY env variable.)
  3. Switch users.
  4. Type xauth add + the entire MAGIC-COOKIE line from above.
  5. Graphics should appear now. Test it with a quick xlogo.
  • no "+" in xauth add. E.g. just xauth add ubuntu/unix:10 MIT-MAGIC-COOKIE-1 6b49de7c34409d5ac69beab31d12ec94 – Tuntable Jun 6 '17 at 3:45
  • USER="otherusername" && MAGIC_COOKIE=`xauth list | tail -n1` && su -c "xauth add $MAGIC_COOKIE" $USER && su - $USER – 7yl4r Apr 12 '18 at 20:43

I like Randy's answer, but it didn't quite work for me.

Here is what I got to work:

  1. ssh -Y as user1
  2. xauth list | grep `uname -n`
  3. Switch to user2
  4. unset XAUTHORITY
  5. xauth generate :0 .
  6. xauth add :0 . <KEY-FROM-STEP-2>

Note the two periods in steps 5 and 6.

If I just follow Randy's answer, user2's XAUTHORITY variable is still pointing to user1's .Xauthority file. And his syntax of the +key didn't work.


This isn't an answer, so if you find one, obviously that is preferable.

If not, and this is the root cause of your conundrum:

The reason I am not ssh'ing directly is because I don't want that user to be accessible through ssh (it is the "virtualbox" user, which is obviously an easy target for bots trying to ssh to that server)...

It seems to me not a great piece of reasoning. "What bots target" WRT a well configured sshd is largely irrelevant. Will they buzz around port 22 all over the place anywhere? Apparently so. Does this mean they actually have a chance of success?

Try googling around for a story about someone who's had a random anonymous bot successfully break into sshd. I'm sure it must have happened to someone somewhere (and, of course, you might never know), but I can't find any reports of such. It would be interesting to read what the configuration used was.

SSH is very secure when used properly. If it weren't, internet commerce would not be feasible. So why do these bots bother? By "used properly" I mean, primarily, with mandatory public/private key pairs. If you do that and are confident your private key is secure (and you should be), be confident about sshd.

I think the reason all the "break-in attempts" happen at all is that there is a large body of users who don't do things like ask questions on U&L ;) and don't read manual pages and use password protection alone, which is sort of like leaving your ATM card in a machine somewhere with a sign saying, "Guess away!".

However, if you think of your private key like your ATM card -- as something that is physically secured by you (which it essentially is), then the target becomes much much more ethereal. All those bots can do is prove that yes, it really would take thousands of machines thousands of years working together to brute force a 2048-bit key.

If you are sick of reading reports of break-in attempts, change your port. I have seen people here poo-poo this as "security by obscurity", however, an sshd which is properly secured on port 22 is not going to be any less secure on port 57, but it won't be randomly bothered. Of course, all your drone enemies could just port scan the whole IP -- but you know what? They don't. I'd presume this is because what they are looking for is someone running a system who hasn't even looked at /etc/ssh/sshd_config, much less educated themselves and tuned it.

  • I agree with all that you say. but I am always insanely insecure (isn't that what they teach you in many situations after you get burned?). To be honest the pc I'm trying to log on to, is being a firewall (no access from outside). It's ssh is on a high port, has a difficult password, but I still can't help but feel that "virtualbox" is a public name. one that someone somewhere may choose to incorporate in a bot code. SSH keys are a wonderful solution especially if used with password protection. But i'd have to have to be carrying a lightweight linux distro on usb if I was to use them. – nass Sep 6 '13 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.