X11 not forwarding

Question

Level 1

0 points

X11 not forwarding

Attempting to get X11 forwarding to work properly on Mountain Lion and not having any success. X11 forwarding is enabled both on the OSX client and on the remote Linux host. I'm using XQuartz for my xterms. ssh -vv shows that forwarding has been accepted, yet everything results in "Can't open display"

bash-3.2$ ssh -vv charlestown\\tgentry@engtools

OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013

debug1: Reading configuration data /Users/tgentry/.ssh/config

debug1: Reading configuration data /etc/ssh_config

debug1: /etc/ssh_config line 53: Applying options for *

debug2: ssh_connect: needpriv 0

debug1: Connecting to engtools [10.0.1.198] port 22.

debug1: Connection established.

debug1: identity file /Users/tgentry/.ssh/id_rsa type 1

debug1: identity file /Users/tgentry/.ssh/id_rsa-cert type -1

debug1: identity file /Users/tgentry/.ssh/id_dsa type -1

debug1: identity file /Users/tgentry/.ssh/id_dsa-cert type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH_4*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.9

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blow fish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-g roup1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: mac_setup: found hmac-md5

debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com

debug2: mac_setup: found hmac-md5

debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 131/256

debug2: bits set: 537/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Server host key: RSA 08:af:be:3a:a0:a6:59:59:4e:7e:7c:14:e0:2a:e6:30

debug1: Host 'engtools' is known and matches the RSA host key.

debug1: Found key in /Users/tgentry/.ssh/known_hosts:2

debug2: bits set: 518/1024

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: Roaming not allowed by server

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: /Users/tgentry/.ssh/id_rsa (0x7fc8c041d400)

debug2: key: /Users/tgentry/.ssh/id_dsa (0x0)

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /Users/tgentry/.ssh/id_rsa

debug2: we sent a publickey packet, wait for reply

debug1: Server accepts key: pkalg ssh-rsa blen 277

debug2: input_userauth_pk_ok: fp d7:32:d2:e8:dc:b8:d0:b8:75:ab:ac:ee:99:5c:7f:4c

debug1: read PEM private key done: type RSA

debug1: Enabling compression at level 6.

debug1: Authentication succeeded (publickey).

Authenticated to engtools ([10.0.1.198]:22).

debug1: channel 0: new [client-session]

debug2: channel 0: send open

debug1: Entering interactive session.

debug2: callback start

debug2: Checking for xauth using /opt/X11/bin/xauth -f /var/folders/hy/m4qgxf0x1v91v8967x0004083thkxz/T//xauth_test exit > /dev/null 2> /dev/null

debug2: x11_get_proto: /opt/X11/bin/xauth list /tmp/launch-slZEdL/org.macosforge.xquartz:0 2>/dev/null

debug1: Requesting X11 forwarding with authentication spoofing.

debug2: channel 0: request x11-req confirm 1

debug2: client_session2_setup: id 0

debug2: fd 3 setting TCP_NODELAY

debug2: channel 0: request pty-req confirm 1

debug2: channel 0: request shell confirm 1

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel_input_status_confirm: type 99 id 0

debug2: X11 forwarding request accepted on channel 0

debug2: channel_input_status_confirm: type 99 id 0

debug2: PTY allocation request accepted on channel 0

debug2: channel 0: rcvd adjust 2097152

debug2: channel_input_status_confirm: type 99 id 0

debug2: shell request accepted on channel 0

Last login: Tue Mar 25 16:31:59 2014 from 10.1.4.123

tgentry@ri-engtools01-$ debug2: client_check_window_change: changed

debug2: channel 0: request window-change confirm 0

debug2: client_check_window_change: changed

debug2: channel 0: request window-change confirm 0

debug2: client_check_window_change: changed

debug2: channel 0: request window-change confirm 0

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

debug2: channel 0: rcvd eof

debug2: channel 0: output open -> drain

debug2: channel 0: obuf empty

debug2: channel 0: close_write

debug2: channel 0: output drain -> closed

debug2: channel 0: rcvd close

debug2: channel 0: close_read

debug2: channel 0: input open -> closed

debug2: channel 0: almost dead

debug2: channel 0: gc: notify user

debug2: channel 0: gc: user detached

debug2: channel 0: send close

debug2: channel 0: is dead

debug2: channel 0: garbage collecting

debug1: channel 0: free: client-session, nchannels 1

Connection to engtools closed.

Transferred: sent 4704, received 3784 bytes, in 337.0 seconds

Bytes per second: sent 14.0, received 11.2

debug1: Exit status 0

debug1: compress outgoing: raw data 2697, compressed 942, factor 0.35

debug1: compress incoming: raw data 1950, compressed 616, factor 0.32

bash-3.2$ ssh -vv charlestown\\tgentry@engtools

OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013

debug1: Reading configuration data /Users/tgentry/.ssh/config

debug1: Reading configuration data /etc/ssh_config

debug1: /etc/ssh_config line 53: Applying options for *

debug2: ssh_connect: needpriv 0

debug1: Connecting to engtools [10.0.1.198] port 22.

debug1: Connection established.

debug1: identity file /Users/tgentry/.ssh/id_rsa type 1

debug1: identity file /Users/tgentry/.ssh/id_rsa-cert type -1

debug1: identity file /Users/tgentry/.ssh/id_dsa type -1

debug1: identity file /Users/tgentry/.ssh/id_dsa-cert type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH_4*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.9

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blow fish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-g roup1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: mac_setup: found hmac-md5

debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com

debug2: mac_setup: found hmac-md5

debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 129/256

debug2: bits set: 502/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Server host key: RSA 08:af:be:3a:a0:a6:59:59:4e:7e:7c:14:e0:2a:e6:30

debug1: Host 'engtools' is known and matches the RSA host key.

debug1: Found key in /Users/tgentry/.ssh/known_hosts:2

debug2: bits set: 518/1024

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: Roaming not allowed by server

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: /Users/tgentry/.ssh/id_rsa (0x7fe4f2c1d400)

debug2: key: /Users/tgentry/.ssh/id_dsa (0x0)

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /Users/tgentry/.ssh/id_rsa

debug2: we sent a publickey packet, wait for reply

debug1: Server accepts key: pkalg ssh-rsa blen 277

debug2: input_userauth_pk_ok: fp d7:32:d2:e8:dc:b8:d0:b8:75:ab:ac:ee:99:5c:7f:4c

debug1: read PEM private key done: type RSA

debug1: Enabling compression at level 6.

debug1: Authentication succeeded (publickey).

Authenticated to engtools ([10.0.1.198]:22).

debug1: channel 0: new [client-session]

debug2: channel 0: send open

debug1: Entering interactive session.

debug2: callback start

debug2: Checking for xauth using /opt/X11/bin/xauth -f /var/folders/hy/m4qgxf0x1v91v8967x0004083thkxz/T//xauth_test exit > /dev/null 2> /dev/null

debug2: x11_get_proto: /opt/X11/bin/xauth list /tmp/launch-slZEdL/org.macosforge.xquartz:0 2>/dev/null

debug1: Requesting X11 forwarding with authentication spoofing.

debug2: channel 0: request x11-req confirm 1

debug2: client_session2_setup: id 0

debug2: fd 3 setting TCP_NODELAY

debug2: channel 0: request pty-req confirm 1

debug2: channel 0: request shell confirm 1

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel_input_status_confirm: type 99 id 0

debug2: X11 forwarding request accepted on channel 0

debug2: channel_input_status_confirm: type 99 id 0

debug2: PTY allocation request accepted on channel 0

debug2: channel 0: rcvd adjust 2097152

debug2: channel_input_status_confirm: type 99 id 0

debug2: shell request accepted on channel 0

Last login: Tue Mar 25 16:38:20 2014 from 10.1.4.123

tgentry@ri-engtools01-$ xlogo

Error: Can't open display: 10.1.4.123:0.0

tgentry@ri-engtools01-$

Feedback would be appreciated.

OS X Mountain Lion (10.8.5)

Posted on Mar 25, 2014 1:49 PM

Reply

Answer 1

Mar 25, 2014 6:57 PM in response to tagentry

I would start here X11-UsersFAQ – XQuartz

BTW is this a new install or has it workd and stopped?

Reply

Answer 2

BobHarris

Level 9

56,933 points

Mar 25, 2014 9:02 PM in response to tagentry

Suggest trying

ssh -X destination.host.name

or -Y

and make sure DISPLAY is NOT being set by a shell initialization script.

ssh -X should create its own DISPLAY with a value such as localhost:10.0

note, I use ssh -X and -Y all day, everyday at work, with X11 output displayed on my Mac from several different Unix and Linux systems.

Message was edited by: BobHarris

Reply

Answer 3

tagentry Author

Level 1

0 points

Mar 26, 2014 7:08 AM in response to Frank Caggiano

I will review the User FAQ again, thx

Reply

Answer 4

tagentry Author

Level 1

0 points

Mar 26, 2014 7:11 AM in response to BobHarris

X11 forwarding is enabled as can be seen with the following

debug1: Requesting X11 forwarding with authentication spoofing.

debug2: X11 forwarding request accepted on channel 0

Enabling X11 forwarding in /etc/ssh_config is the same as using -X or -Y

This worked prior to Mountain Lion without having forwarding enabled on the client. Just for the latency reasons alone, I prefer to run my tools locally, so I have my own workarounds, however I'm now supporting users that are local to the server and prefer to use the server resources.

Reply

Answer 5

Mar 26, 2014 7:21 AM in response to tagentry

tagentry wrote:

I will review the User FAQ again, thx

There is specifically this section ssh X forwarding debugging.

Have you run the steps suggested and did the output match what is expected?

Reply

Answer 6

tagentry Author

Level 1

0 points

Mar 26, 2014 7:26 AM in response to Frank Caggiano

Yes I have. My only difference is the DISPLAY variable on the remote server is [my ip]:0.0 instead of localhost, however, I don't see how that would prevent it from working. I am doing more research on the Redhat server as I did add an offset of 10 to the ssd_config and that didn't change the display variable at all.

Reply

Answer 7

BobHarris

Level 9

56,933 points

Mar 26, 2014 7:31 AM in response to tagentry

If your Mac OS X X11 Display server is properly forwarded, as in -X or -Y, would have the remote system's DISPLAY environment variable holding something like

DISPLAY=localhost:10.0

It would not be 10.1.4.123:0.0, which is in the error message:

Error: Can't open display: 10.1.4.123:0.0

10.1.4.123:0.0 implies that you are NOT using the ssh X11 tunnel that -X or -Y would create, but rather you are attempting to directly connect to the Mac OS X X11 Display server without using the ssh X11 tunnel.

Also, you should at least experiment with -X or -Y to see if that does work as expected, and even compare the ssh debug output from your setup vs an -X or -Y connection. It may be useful.

Message was edited by: BobHarris

Reply

Answer 8

BobHarris

Level 9

56,933 points

Mar 26, 2014 7:34 AM in response to tagentry

My only difference is the DISPLAY variable on the remote server is [my ip]:0.0 instead of localhost, however, I don't see how that would prevent it from working.

The localhost:10.0 notation says to connect to the local end of the ssh tunnel.

The 10.2.4.123:0.0 says make a new connection over the internet directly to the Mac, and will not use the ssh tunnel which has already paved the way to your Mac's X11 Display Server.

Reply

Answer 9

tagentry Author

Level 1

0 points

Mar 26, 2014 7:38 AM in response to BobHarris

I confirmed before even posting that those debug statements would not appear if the local client wasn't attempting X11 Forwarding. At this point, I'm trying to figure out why Redhat is overriding this.

Reply

Answer 10

tagentry Author

Level 1

0 points

Mar 26, 2014 8:45 AM in response to tagentry

Just to confirm forwarding is working and I'm now down to something in Redhat, I exported my display to localhost:10.0 and forwarding worked correctly. I can set this with the .bash_profile, but I really need to find what is overriding the ssh forward to start with. I'll take any ideas on that as well. Off to more research.

Reply

Answer 11

tagentry Author

Level 1

0 points

Mar 26, 2014 9:11 AM in response to tagentry

I found my answer.

The previous administrator added an explicit definition for DISPLAY in .bash_profile setting it to $REMOTEIP:0.0 instead of utilizing X11 Forwarding. Removing that entry from .bash_profile allowed ssh forwarding to work.

Sweet. Thx for all the input.

Reply