X authentication is based on cookies — secret little pieces of random data
that only you and the X server know… So, you need to let the other user in
on what your cookie is. One way to do this is as follows:
Before you issue the su or sudo (but after having ssh'ed into the remote
system), request the cookie for the current DISPLAY that's connecting to
your X server:
You'll get something like
somehost.somedomain:10 mit-magic-cookie-1 4d22408a71a55b41ccd1657d377923ae
Then, after having done su, tell the new user what the cookie is:
$ xauth add somehost.somedomain:10 MIT-MAGIC-COOKIE-1 4d22408a71a55b41ccd1657d377923ae
(just copy'n-paste the output of the above 'xauth list' onto 'xauth add')
That's it. Now, you _should_ be able to start any X application.
documented on: 29 Jan 2007, daveseff
Getting X11 forwarding through ssh working after running su
I don't believe the timing of this article! :)
I'd been struggling with this recently:
I can't login as user B directly on a Solaris box.
I login as user A, then su to B. Of course, X forwarding stops working. And
I need X working to install some proprietary software.
Then I see this article that explains precisely how!
Getting X11 forwarding through ssh working after running su
Another technique I discovered recently (after getting stuck on a SLES
system with no sux packages) is to set the XAUTHORITY environment variable
to $USER/.Xauthority (where $USER is the username you ssh'd in as).
Getting X11 forwarding through ssh working after running su
You can use the sux package too (with the command of the same name).
similarly there is a gksu package that provides gksu and gksudo.
Getting X11 forwarding through ssh working after running su
> will the trick works on chroot as well, provided everything eg /dev /proc
> are properly bind mounted?
Yep, it works, after I bind mount /tmp as well!
> $ xauth list
>
> seems to takes years to report the cookie...
That's because some left-over cookies, try specify which cookie to list:
xauth list somehost.somedomain:10
Getting X11 forwarding through ssh working after running su
#Asssuming you did
ssh -X user@hostname
# Gain root privileges,
su -
# and merge the Xauth information like this:
xauth merge /home/user/.Xauthority
Getting X11 forwarding through ssh working after running su
> Another really really simple alternative is to ssh again to root@localhost.
I didn't say anything about root. Root is easy. You usually can run 'sudo
xapplication' and be happy with that. As an administrator, which is what
this site is about, sometimes you have to help troubleshoot things for other
users and you need to 'sudo su - username' to see the problem from their
perspective. When you sudo su, or su in general you loose your DISPLAY and
Xauth settings.
documented on: 29 Jan 2007, daveseff
Why is the X11 Forwarding not working on my system when my ssh daemon is
correctly configured with 'X11Forwarding yes'?
The easiest way to debug the ssh connection is to run ssh with increased
verbosity. This normally shows many silent errors/problems.
In order to increase verbosity, issue the following command:
$ ssh -v -X -l root <USERNAME>
The output would look like the following:
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to cs1 [192.168.161.134] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'cs1' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:37
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/identity
debug1: Server accepts key: pkalg ssh-dss blen 816
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Remote: No xauth program; cannot forward with spoofing.
Last login: Mon Aug 14 14:17:11 2006 from 192.168.161.1
From the example output above, there are two lines of interest. Check the
following lines:
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Remote: No xauth program; cannot forward with spoofing.
In this case, the xauth program is not installed in the system, and
therefore the ssh target system can not add itself to the X authentication
database of the X server, so Xforwarding is silently denied. To resolve the
problem, install the xauth package:
try to ssh in to the machine and verify that the display environment
variable is correctly setup by the tunnel:
$ ssh -X -l root <USERNAME>
# echo $DISPLAY
localhost:10.0
documented on: 2007.01.31
sunshine
If the DISPLAY variable is set on the client side, the server will
create a dummy X server and set DISPLAY accordingly. Any connections
to the dummy X server will be forwarded through the secure channel,
and will be made to the real X server from the client side. An
arbitrary number of X programs can be started during the session, and
starting them does not require anything special from the user.
|
the user must not manually set DISPLAY, because then it would
connect directly to the real display instead of going through the
encrypted channel). |
$ ssh -l user sunshine
>echo $DISPLAY
sunshine:10.0
— the 10 instead of 0, the dummy X
