X11 forwarding via SSH and su
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
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
^C
mahmood@cluster:~$ su
Password:
root@cluster:mahmood# xclock
^C
root@cluster:mahmood# su - hmousavi
hmousavi@cluster:~$ xclock
MobaXterm X11 proxy: Authorisation not recognised
Error: Can't open display: localhost:10.0
hmousavi@cluster:~$
P.S: ^C means that I was able to see the xclock window, so I pressed ^C to return to the terminal.
ssh x11 su
edited May 16 '16 at 23:17
Gilles
513k12010151547
asked May 16 '16 at 18:36
mahmood
299517
add a comment |Â
up vote
2
down vote
favorite
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
^C
mahmood@cluster:~$ su
Password:
root@cluster:mahmood# xclock
^C
root@cluster:mahmood# su - hmousavi
hmousavi@cluster:~$ xclock
MobaXterm X11 proxy: Authorisation not recognised
Error: Can't open display: localhost:10.0
hmousavi@cluster:~$
P.S: ^C means that I was able to see the xclock window, so I pressed ^C to return to the terminal.
ssh x11 su
edited May 16 '16 at 23:17
Gilles
513k12010151547
asked May 16 '16 at 18:36
mahmood
299517
Have you triedsu --preserve-environment - hmousavito preserve the enviroment variableDISPLAY?
– Anthon
May 16 '16 at 18:50
Doesn't work eitherMobaXterm X11 proxy: Authorisation not recognised \ Error: Can't open display: localhost:10.0
– mahmood
May 17 '16 at 7:45
Trysu -instead ofsu.
– Thorbjørn Ravn Andersen
Mar 26 at 13:58
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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
^C
mahmood@cluster:~$ su
Password:
root@cluster:mahmood# xclock
^C
root@cluster:mahmood# su - hmousavi
hmousavi@cluster:~$ xclock
MobaXterm X11 proxy: Authorisation not recognised
Error: Can't open display: localhost:10.0
hmousavi@cluster:~$
P.S: ^C means that I was able to see the xclock window, so I pressed ^C to return to the terminal.
ssh x11 su
edited May 16 '16 at 23:17
Gilles
513k12010151547
asked May 16 '16 at 18:36
mahmood
299517
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
^C
mahmood@cluster:~$ su
Password:
root@cluster:mahmood# xclock
^C
root@cluster:mahmood# su - hmousavi
hmousavi@cluster:~$ xclock
MobaXterm X11 proxy: Authorisation not recognised
Error: Can't open display: localhost:10.0
hmousavi@cluster:~$
P.S: ^C means that I was able to see the xclock window, so I pressed ^C to return to the terminal.
ssh x11 su
ssh x11 su
edited May 16 '16 at 23:17
Gilles
513k12010151547
asked May 16 '16 at 18:36
mahmood
299517
edited May 16 '16 at 23:17
Gilles
513k12010151547
asked May 16 '16 at 18:36
mahmood
299517
edited May 16 '16 at 23:17
Gilles
513k12010151547
edited May 16 '16 at 23:17
Gilles
513k12010151547
edited May 16 '16 at 23:17
Gilles
513k12010151547
513k12010151547
asked May 16 '16 at 18:36
mahmood
299517
asked May 16 '16 at 18:36
mahmood
299517
asked May 16 '16 at 18:36
mahmood
299517
299517
Have you triedsu --preserve-environment - hmousavito preserve the enviroment variableDISPLAY?
– Anthon
May 16 '16 at 18:50
Doesn't work eitherMobaXterm X11 proxy: Authorisation not recognised \ Error: Can't open display: localhost:10.0
– mahmood
May 17 '16 at 7:45
Trysu -instead ofsu.
– Thorbjørn Ravn Andersen
Mar 26 at 13:58
add a comment |Â
Have you triedsu --preserve-environment - hmousavito preserve the enviroment variableDISPLAY?
– Anthon
May 16 '16 at 18:50
Doesn't work eitherMobaXterm X11 proxy: Authorisation not recognised \ Error: Can't open display: localhost:10.0
– mahmood
May 17 '16 at 7:45
Trysu -instead ofsu.
– Thorbjørn Ravn Andersen
Mar 26 at 13:58
Have you tried
su --preserve-environment - hmousavi to preserve the enviroment variable DISPLAY?– Anthon
May 16 '16 at 18:50
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
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 at 13:58
Try
su - instead of su.– Thorbjørn Ravn Andersen
Mar 26 at 13:58
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
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.
answered May 16 '16 at 23:17
Gilles
513k12010151547
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, runssh-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 commandssh-keygenbut 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
 |Â
show 2 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
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.
answered May 16 '16 at 23:17
Gilles
513k12010151547
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, runssh-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 commandssh-keygenbut 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
 |Â
show 2 more comments
up vote
0
down vote
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.
answered May 16 '16 at 23:17
Gilles
513k12010151547
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, runssh-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 commandssh-keygenbut 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
 |Â
show 2 more comments
up vote
0
down vote
up vote
0
down vote
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.
answered May 16 '16 at 23:17
Gilles
513k12010151547
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.
answered May 16 '16 at 23:17
Gilles
513k12010151547
edited Jun 29 at 18:33
answered May 16 '16 at 23:17
Gilles
513k12010151547
answered May 16 '16 at 23:17
Gilles
513k12010151547
answered May 16 '16 at 23:17
Gilles
513k12010151547
513k12010151547
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, runssh-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 commandssh-keygenbut 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
 |Â
show 2 more comments
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, runssh-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 commandssh-keygenbut 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
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
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
@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
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
@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
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
 |Â
show 2 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f283498%2fx11-forwarding-via-ssh-and-su%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Have you tried
su --preserve-environment - hmousavito preserve the enviroment variableDISPLAY?– 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 ofsu.– Thorbjørn Ravn Andersen
Mar 26 at 13:58