No more X11 forwarding in ssh -Y or ssh -X, why? [SOLVED]

Message

rsa4046 · Post by **rsa4046** » Wed Dec 10, 2008 5:52 pm

I've got the same apparent problem as in this post , in that ssh X forwarding (which used to work some time ago) now doesn't. In the sample below, L and R prompts designate the machine (local or remote):

Code: Select all

L$ xauth list
192.168.0.2:0  MIT-MAGIC-COOKIE-1  995e59b9f6262b7025d43f0aebd5d9d1
localmachine/unix:0  MIT-MAGIC-COOKIE-1  995e59b9f6262b7025d43f0aebd5d9d1

L$ ssh user@remoteserver -Y
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Wed Dec 10 11:42:12 CST 2008 from local.ip.net on pts/0
Last login: Wed Dec 10 11:43:01 2008 from local.ip.net

R$ xterm
Xlib: connection to "localhost:10.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
xterm Xt error: Can't open display: localhost:10.0

R$ xauth list
remoteserver/unix:10  MIT-MAGIC-COOKIE-1  5e7e5d526c94f980779c40857d3f1f69

Here's a listing of the ssh_config and sshd_config on the local machine (comments removed)

Code: Select all

L# sed '/^\#/d;/^$/d' /etc/ssh/ssh_config
ForwardX11 yes
XAuthLocation /usr/bin/xauth

L# sed '/^\#/d;/^$/d' /etc/ssh/sshd_config
AddressFamily inet
ListenAddress 0.0.0.0
X11UseLocalhost yes
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UsePAM yes
AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
Subsystem       sftp    /usr/lib64/misc/sftp-server

and the remote server

Code: Select all

R# sed '/^\#/d;/^$/d' /etc/ssh/ssh_config
ForwardX11 yes
XAuthLocation /usr/bin/xauth

R# sed '/^\#/d;/^$/d' /etc/ssh/sshd_config
AddressFamily inet
ListenAddress 0.0.0.0
X11UseLocalhost yes
Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
UsePAM yes
AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
Subsystem       sftp    /usr/lib64/misc/sftp-server

Any ssh Xperts have an idea why this no longer works? xauth seems to be in the path on both machines. I can login fine, just can't use any X commands while logged in to the remote via ssh remote -X or ssh remote -Y. One other thing, anyone know why I'm getting two "Last login" messages after logging in?

coolsnowmen · Post by **coolsnowmen** » Wed Dec 17, 2008 9:04 am

can you try removing both local and remote ~/.Xauthority files, and then ssh -XY again.

also try with

xhost +

on remote machine

rsa4046 · Post by **rsa4046** » Wed Dec 17, 2008 5:04 pm

Thanks for the reply coolsnowmen. I've tried your suggestion, but with no success

: Here's what I did:
On remote machine:

Logged in.
Became root.
Stopped X (/etc/init.d/xdm stop)
Wiped all .Xauthority files
Restarted X (/etc/init.d/xdm start).
Logged out.

On local machine, similar sequence:

As root, stopped X, wiped all local .Xauthority files.
Logged in as user.
Started kde (startx).
From bash konsole tried:

Code: Select all

$ ssh remotehost -Y
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Wed Dec 17 10:33:36 2008 from <snip>
/usr/bin/xauth:  creating new authority file /home/rolf/.Xauthority
$ xterm
Xlib: connection to "localhost:10.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
xterm Xt error: Can't open display: localhost:10.0
$ xhost +
Xlib: connection to "localhost:10.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
xhost:  unable to open display "localhost:10.0"

At the moment, /etc/ssh/sshd_config on the remote machine has only

Code: Select all

Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM no
X11Forwarding yes
Subsystem       sftp    /usr/lib64/misc/sftp-server

I don't understand whether I've made some change inadvertently, or if ssh or X11 forwarding have changed somehow, but this forwarding (with either -X or -Y) used to work ...

Is anyone else having this problem? Google is full of similar posts, but many of these seemed to be related to bad xauth path. The remote host clearly can find /usr/bin/xauth and creates a new .Xauthority file for the user, but this file doesn't seem to contain a valid cookie ...

Any ideas?

Devport · Post by **Devport** » Wed Dec 17, 2008 5:14 pm

Did you update to glibc-2.9 ( I have xauth problems using gksu since the update ).

rsa4046 · Post by **rsa4046** » Wed Dec 17, 2008 6:23 pm

Devport wrote:Did you update to glibc-2.9 ( I have xauth problems using gksu since the update ).

Thanks Devport, I have

Code: Select all

$ emerge -vp glibc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-libs/glibc-2.9_p20081201  USE="(multilib) nls -debug -gd -glibc-compat20 -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

FWIW, I also tried stopping the X server on the remote host, and following the last post in this topic then did:

Code: Select all

$ ssh -Y -vvv -l user remote.host.edu
OpenSSH_5.1p1, OpenSSL 0.9.8h 28 May 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0                       
debug1: Connecting to remote.host.edu [<snip>] port 22.
debug1: Connection established.                             

<snip .. ssh key exchange authentication blather >

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.12
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received

<snip .. ssh key exchange authentication blather >

debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received

<snip .. ssh key exchange authentication blather >

debug3: sign_and_send_pubkey
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Dec 17 11:24:12 2008 from my.local.ip
$

Now I try xclock

Code: Select all

$ xclock                                                                   
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 43084
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 1: read<=0 rfd 7 len 0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug2: channel 1: send close
Xlib: connection to "localhost:10.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Error: Can't open display: localhost:10.0
debug3: channel 1: will not send data after close
debug3: channel 1: will not send data after close
debug3: channel 1: will not send data after close
debug3: channel 1: will not send data after close
debug3: channel 1: will not send data after close
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/2 fd 4/5 cfd -1)
  #1 x11 (t4 r3 i3/0 o3/0 fd 7/7 cfd -1)

debug3: channel 1: close_fds r 7 w 7 e -1 c -1
$

The principal difference between this response and the post cited above comes right after confirm x11, where ssh has some apparent difficulty reading channel 1:

Code: Select all

debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 1: read<=0 rfd 7 len 0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug2: channel 1: send close

Compared to the successful one in the post cited

Code: Select all

debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 1: rcvd adjust 40220
debug2: channel 1: rcvd adjust 49152
....
....
debug2: channel 1: rcvd adjust 49152
debug2: channel 1: rcvd eof

So it seems my session isn't reading something (what, the cookie?) correctly ... is this a bug? For security's sake, I do have public key authentication (only, i.e. PasswordAuthentication no set in remote sshd_config) working OK (together with ssh-agent, keychain, etc.) and do use a passphrase. Any insight or ideas are sure welcome.

Edit, cleaned up stray whitespace and and added:
Also, in same debug session after xclock fails:

Code: Select all

$ xauth list
remotemachine/unix:10  MIT-MAGIC-COOKIE-1  bf2091f91ba4f3ac73e7faf5e0435f3d

Devport · Post by **Devport** » Wed Dec 17, 2008 6:34 pm

Okay now I am pretty sure that it is caused by glibc-2.9 which cant be downgraded to double check ...

https://bugs.gentoo.org/show_bug.cgi?id=251338

I added a topic about downgrading glibc - I am pretty sure your X over ssh will work again with glibc < 2.9.

http://forums.gentoo.org/viewtopic-p-53 ... ml#5318819

rsa4046 · Post by **rsa4046** » Wed Dec 17, 2008 7:02 pm

Devport wrote:Okay now I am pretty sure that it is caused by glibc-2.9 which cant be downgraded to double check ...

https://bugs.gentoo.org/show_bug.cgi?id=251338

I added a topic about downgrading glibc - I am pretty sure your X over ssh will work again with glibc < 2.9.

http://forums.gentoo.org/viewtopic-p-53 ... ml#5318819

Thanks Devport: if I try to downgrade?

Code: Select all

# emerge -vp =sys-libs/glibc-2.8_p20080602-r1

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     UD] sys-libs/glibc-2.8_p20080602-r1 [2.9_p20081201] USE="nls -debug -gd -glibc-compat20 -glibc-omitfp (-hardened) (-multilib) -profile (-selinux) -vanilla" 96 kB

Total: 1 package (1 downgrade), Size of downloads: 96 kB

Will I run the risk to breaking other things? Would downgrading glibc create inconsistent linking that would necessitate rebuilding much / most of the rest of the system?

Devport · Post by **Devport** » Wed Dec 17, 2008 7:09 pm

rsa4046 wrote:Will I run the risk to breaking other things? Would downgrading glibc create inconsistent linking that would necessitate rebuilding much / most of the rest of the system?

It is said to be dangerous and may break the system completely. Personaly I would expect it not be so dangerous because actually most things are linked dynamically and glibc didnt break the interface ( ABI ). I try to downgrade now and will post my sucess / failure status. You should wait at least until I am done.

rsa4046 · Post by **rsa4046** » Wed Dec 17, 2008 7:11 pm

Devport wrote:
rsa4046 wrote:Will I run the risk to breaking other things? Would downgrading glibc create inconsistent linking that would necessitate rebuilding much / most of the rest of the system?
It is said to be dangerous and may break the system completely. Personaly I would expect it not be so dangerous because actually most things are linked dynamically and glibc didnt break the interface ( ABI ). I try to downgrade now and will post my sucess / failure status. You should wait at least until I am done.

Thanks Devport!
Edit, added: this post doesn't sound auspicious

Devport · Post by **Devport** » Wed Dec 17, 2008 8:26 pm

Done. I emerged glibc-2.8 by masking 2.9 and modifying the glibc ebuild as mentioned in your link. A simple emerge -av1 glibc worked just fine. gksu is working again and I suppose your X over ssh would work as well. Even though it worked fine for me be careful and do at least a quickpkg glibc before downgrading.

rsa4046 · Post by **rsa4046** » Wed Dec 17, 2008 8:52 pm

Devport, I will give this a try tonight and post back. Thanks again for your help. Cheers, Rolf

rsa4046 · Post by **rsa4046** » Thu Dec 18, 2008 3:14 am

Devport, an update:

Code: Select all

$ ssh -Y -vvv -l rolf remotemachine.edu
OpenSSH_5.1p1, OpenSSL 0.9.8h 28 May 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0                       
debug1: Connecting to carbon.rice.edu [168.7.78.33] port 22.
debug1: Connection established.                             

<snip:openssh public key exchange blather>

debug1: Authentication succeeded (publickey).                                       
debug1: channel 0: new [client-session]                                             
debug3: ssh_session2_open: channel_new: 0                                           
debug2: channel 0: send open                                                        
debug1: Requesting no-more-sessions@openssh.com                                     
debug1: Entering interactive session.                                               
debug2: callback start                                                              
debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null                          
debug1: Requesting X11 forwarding with authentication spoofing.                     
debug2: channel 0: request x11-req confirm 0                                        
debug1: Requesting authentication agent forwarding.                                 
debug2: channel 0: request auth-agent-req@openssh.com confirm 0                     
debug2: client_session2_setup: id 0                                                 
debug2: channel 0: request pty-req confirm 1                                        
debug3: tty_make_modes: ospeed 38400                                                
debug3: tty_make_modes: ispeed 38400                                                
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Dec 17 20:55:06 2008 from <hidden>

$ xeyes

debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 38593
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11

Hooah, Devport. You're the man: it works! THANKS

!!!!!!!!!!!
So glibc-2.9 was the culprit, and (amazingly) no hitches in my backpedal to glibc-2.8:

Code: Select all

$ equery l glibc
[ Searching for package 'glibc' in all categories among: ]
 * installed packages
[I--] [ ~] sys-libs/glibc-2.8_p20080602-r1 (2.2)

Will make a note on your bug report.Thanks again!
Cheers, Rolf

Addendum:
Per openssh's FAQ, the only statements necessary to get forwarding to roll were the following (on both local and remote hosts):

Code: Select all

The default configuration files disable authentication agent and X11 forwarding. To enable it, put the line below in sshd_config:

    X11Forwarding yes

and put the following lines in ssh_config:

    ForwardAgent yes
    ForwardX11 yes

Devport · Post by **Devport** » Thu Dec 18, 2008 4:10 am

I am glad it worked for you too. And your topic made me solve my issue as well since I was as of then unsure if glibc-2.9 was the cause. I even answered to your topic almost immediatly but deleted it again because I was unsure ...

robbyjo · Post by **robbyjo** » Thu Mar 26, 2009 8:54 pm

Is the newer glibc-2.9_p20081201-r2 solves this problem yet? The following bug thread:
http://bugs.gentoo.org/251338

indicates that the bug still stands. But post #6 of that thread seems to indicate it's solved. Can anyone confirm? I don't want to experience the nightmare of downgrading glibc.

rsa4046 · Post by **rsa4046** » Thu Mar 26, 2009 10:37 pm

Here's what I have with glibc-2.9 on a local and remote machine: untrusted forwarding fails

Code: Select all

local $ equery l glibc
  [ Searching for package 'glibc' in all categories among: ]
   * installed packages
  [I--] [ ~] sys-libs/glibc-2.9_p20081201-r2 (2.2)
local $ ssh remote.machine -X
   Warning: untrusted X11 forwarding setup failed: xauth key data not generated
   Warning: No xauth data; using fake authentication data for X11 forwarding.
remote $ equery l glibc
   [ Searching for package 'glibc' in all categories among: ]
    * installed packages
   [I--] [ ~] sys-libs/glibc-2.9_p20081201-r2 (2.2)
remote $ xeyes &
   Xlib: connection to "localhost:10.0" refused by server
   Xlib: Invalid MIT-MAGIC-COOKIE-1 key
   Error: Can't open display: localhost:10.0
   [1] 32169
   [1]+  Exit 1                  xeyes
remote $ logout
   Connection to remote.machine closed.

But trusted X11 forwarding does seem to work:

Code: Select all

local $ ssh remote.machine -Y
remote $ xeyes &
   [1] 32207
<X app works on local display>
remote $ pkill xeyes
   [1]+  Terminated              xeyes
remote $ logout
   Connection to remote.machine closed.

Princess Nell · Post by **Princess Nell** » Wed Apr 08, 2009 8:06 pm

Hhm. I have the same problem, but am using glibc-2.8_p20080602-r1.

robbyjo · Post by **robbyjo** » Fri Apr 17, 2009 4:00 pm

I finally took the plunge. You need to add the following lines in your /etc/ssh/ssh_config:

Code: Select all

ForwardX11 yes
ForwardX11Trusted yes

It works alright with both glibc 2.8 and 2.9.

urcindalo · Post by **urcindalo** » Thu Nov 05, 2009 5:50 pm

rsa4046 wrote:Addendum:
Per openssh's FAQ, the only statements necessary to get forwarding to roll were the following (on both local and remote hosts):
Code: Select all
The default configuration files disable authentication agent and X11 forwarding. To enable it, put the line below in sshd_config:

    X11Forwarding yes

and put the following lines in ssh_config:

    ForwardAgent yes
    ForwardX11 yes

It doesn't work for me. I get the

Code: Select all

Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.

error

I already read this thread entirely. I use stable AMD64 boxes with just a few ~ packages, mainly scientific ones, so my installed glibc is:

Code: Select all

$ eix -I glibc
[I] sys-libs/glibc
     Available versions:  (2.2)  [P]*2.2.5-r10!s [P]2.3.2-r12!s [P]2.3.5-r3!s [P]2.3.6-r4!s [P]2.3.6-r5!s 2.4-r4!s 2.5-r2!s 2.5-r3!s 2.5-r4!s **2.5.1!s ~2.6!s 2.6.1!s ~2.7-r2!s ~2.8_p20080602!s 2.8_p20080602-r1!s ~2.9_p20081201!s ~2.9_p20081201-r1!s 2.9_p20081201-r2!s ~2.9_p20081201-r3!s ~2.10.1!s
        {build crosscompile_opts_headers-only debug erandom gd glibc-compat20 glibc-omitfp hardened linuxthreads-tls multilib nls nptl nptlonly profile selinux userlocales vanilla}
     Installed versions:  2.9_p20081201-r2(2.2)!s(05:27:28 27/08/09)(multilib nls -crosscompile_opts_headers-only -debug -gd -glibc-omitfp -hardened -profile -selinux -vanilla)
     Homepage:            http://www.gnu.org/software/libc/libc.html
     Description:         GNU libc6 (also called glibc2) C library

$

Any help is greatly appreciated. Thanks in advance.

dmpogo · Post by **dmpogo** » Thu Nov 05, 2009 6:23 pm

Untrusted forwarding is essentially broken. One should use the trusted one

So

ForwardX11Trusted yes

is ssh config files or

ssh -Y somebody@somewhere

on command line.

urcindalo · Post by **urcindalo** » Thu Nov 05, 2009 11:05 pm

dmpogo wrote:Untrusted forwarding is essentially broken. One should use the trusted one

Thanks very much. Your indications worked.

holmberm · Post by **holmberm** » Mon Aug 02, 2010 10:13 pm

This may be slightly OT, and in an old thread no less...

Could any of you well informed gurus give a verbose explanation about the state of X forwarding over ssh? I've read all I could find on the subject but I don't know what to use. man ssh says that ssh -Y can make attackers able to monitor keystrokes etc. (when is this a realistic threat? Certain kinds of hosts?). But the rest of the world (including dmpogo and some people on http://bugs.gentoo.org/237778) say that ssh -X is unsafe/broken/evil, and I don't know what to make of it. Please enlighten me;)

FreakNigh · Post by **FreakNigh** » Sun Apr 17, 2016 7:03 pm

For me the final change I had to make was modify -

~/.ssh/config

and add in -

ForwardX11Trusted yes
ForwardX11 yes

Also pretty sure I had to recompile openssh with +X.

mole · Post by **mole** » Tue May 03, 2016 10:20 pm

Old thread, posting a tip here as it might save someone a lot of time...

If you have an SSD and mount /tmp and /var/tmp using tmpfs to save disk wear, it will likely break X forwarding over SSH.

Once I mounted /tmp and /var/tmp normally, X forwarding worked over SSH again.

hkmaly · Post by **hkmaly** » Mon Jun 28, 2021 6:37 am

coolsnowmen wrote:can you try removing both local and remote ~/.Xauthority files, and then ssh -XY again.

also try with
xhost +
on remote machine

Old thread, but just note:

xhost +

basically says "anyone is allowed to connect to the X server". May be ok to "just try if it works", but is security risk long-term. You should be able to make it work without xhost, just with xauth (which is generally started automatically and uses the ~/.Xauthority file)