For me, it is weird that while using ssh connection with X11 forwarding, a user and root are able to see xclock, but another user is not able to see that. Why?

mahmood@cluster:~$ xclock
mahmood@cluster:~$ su
root@cluster:mahmood# xclock
root@cluster:mahmood# su - hmousavi
hmousavi@cluster:~$ xclock
MobaXterm X11 proxy: Authorisation not recognised
Error: Can't open display: localhost:10.0

P.S: ^C means that I was able to see the xclock window, so I pressed ^C to return to the terminal.

  • Have you tried su --preserve-environment - hmousavi to preserve the enviroment variable DISPLAY? – Anthon May 16 '16 at 18:50
  • Doesn't work either MobaXterm X11 proxy: Authorisation not recognised \\ Error: Can't open display: localhost:10.0 – mahmood May 17 '16 at 7:45
  • Try su - instead of su. – Thorbjørn Ravn Andersen Mar 26 '18 at 13:58

Connecting to an X11 display requires two pieces of information: the display name (normally passed in the DISPLAY environment variable) and the cookie, which is a password for the display that every application must show when connecting. Typically the cookie is stored in ~/.Xauthority, but it can be stored in a different file indicated by the XAUTHORITY environment variable.

It appears that the value of DISPLAY set by SSH was preserved by the two calls to su. However the cookie is in ~mahmood/.Xauthority; when you run a program as hmousavi, the program looks for a cookie in ~hmousavi/.Xauthority and finds a different value.

In principle you could run XAUTHORITY=~mahmood/.Xauthority xclock, but hmousavi presumably doesn't have the permission to read that file — the .Xauthority file should not be readable to other users. You can use the xauth command twice, once as mahmood to extract the cookie value (xauth list localhost:10.0) and once as hmousavi to import that value (xauth merge), but that's cumbersome. The easiest way to make X11 applications work is to use SSH all the way, because SSH sets up X11 forwarding automatically:

mahmood@cluster:~$ ssh -X hmousavi@localhost
hmousavi@cluster:~$ xclock

Add mahmood's SSH public key to hmousavi's .ssh/authorized_keys to allow this.

  • What is the command for the last line? Just want to be sure that I am doing exactly what you said – mahmood May 17 '16 at 7:44
  • @mahmood From mahmood's account, run ssh-copy-id hmousavi@localhost. Or, if you're connecting to mahmood@cluster over SSH, maybe you could connect directly to the hmousavi account instead. – Gilles May 17 '16 at 9:05
  • It says /usr/bin/ssh-copy-id: ERROR: No identities found – mahmood May 17 '16 at 11:47
  • @mahmood That means the account doesn't have a key. You can create one, or use the one from your client machine, or use hmousavi's password if that's permitted by the SSH server configuration. – Gilles May 17 '16 at 11:50
  • Can you edit the answer for supplying those information? I know the command ssh-keygen but since the cluster is based on Rocks, I want to be sure that modifying the ssh keys has no side effect on the nodes (the passwordless ssh to nodes) – mahmood May 17 '16 at 15:43

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.