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

## rsa4046

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):

```
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)

```
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

```
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?Last edited by rsa4046 on Thu Dec 18, 2008 3:15 am; edited 1 time in total

----------

## coolsnowmen

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

also try with  *Quote:*   

> xhost +

  on remote machine

----------

## rsa4046

Thanks for the reply coolsnowmen. I've tried your suggestion, but with no success   :Crying or Very sad: : 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:

```
$ 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

```
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 ...   :Evil or Very Mad: 

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 ...   :Question:  Any ideas?

----------

## Devport

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

----------

## rsa4046

 *Devport wrote:*   

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

 Thanks Devport, I have

```
$ 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:

```
$ 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

```
$ 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:

```
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

```
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:

```
$ xauth list

remotemachine/unix:10  MIT-MAGIC-COOKIE-1  bf2091f91ba4f3ac73e7faf5e0435f3d
```

Last edited by rsa4046 on Wed Dec 17, 2008 6:45 pm; edited 1 time in total

----------

## Devport

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.

https://forums.gentoo.org/viewtopic-p-5318819.html#5318819

----------

## rsa4046

 *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.
> ...

 Thanks Devport: if I try to downgrade?

```
# 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

 *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

 *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

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

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

----------

## rsa4046

Devport, an update:

```
$ 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  :Very Happy: !!!!!!!!!!!

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

```
$ 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):

```
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

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 ...   :Laughing: 

----------

## robbyjo

Is the newer glibc-2.9_p20081201-r2 solves this problem yet? The following bug thread:

https://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

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

```
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:

```

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

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

----------

## robbyjo

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

```
ForwardX11 yes

ForwardX11Trusted yes
```

It works alright with both glibc 2.8 and 2.9.

----------

## urcindalo

 *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):
> 
> ```
> ...

 

It doesn't work for me. I get the

```
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:

```
$ 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

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

 *dmpogo wrote:*   

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

 

Thanks very much. Your indications worked.

----------

## holmberm

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 https://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

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

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

 *coolsnowmen wrote:*   

> can you try removing both local and remote ~/.Xauthority files, and then ssh -XY again.
> 
> also try with  *Quote:*   xhost +  on remote machine

 

Old thread, but just note:  *Quote:*   

> 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)

----------

