X11 forwarding via SSH does not work after upgrade to karmic

[LGB [Gábor Lénárt]]

I had a proper configuration on jaunty (sshd_config) so I could ssh into that machine and run X11 applications there with X11 forwarding, so I could use apps fromt here remotely. After upgrade to karmic (same sshd_config on the server, client is not changed) I got this (for example):

xterm Xt error: Can't open display:
xterm: DISPLAY is not set

I've tried ssh -X, -Y and -X -Y too together with no success.

So DISPLAY environment variable is not even set because of some reason, though I found this in /var/log/auth.log:

Sep 22 19:56:02 vega sshd[11206]: error: Failed to allocate internet-domain X11 display socket.

openssh-server:
  Installed: 1:5.1p1-6ubuntu1
  Candidate: 1:5.1p1-6ubuntu1
  Version table:
 *** 1:5.1p1-6ubuntu1 0
        500 http://archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status
xauth:
  Installed: 1:1.0.3-2
  Candidate: 1:1.0.3-2
  Version table:
 *** 1:1.0.3-2 0
        500 http://archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

sshd_config file:

Port 22
ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 600
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
PasswordAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
PermitTunnel yes
PermitRootLogin forced-commands-only

[LGB [Gábor Lénárt] (lgb)]

Also I am not sure if it's related but if I do X forwarding via SSH _from_ that karmic box, it works, but I got this message too:

Warning: No xauth data; using fake authentication data for X11 forwarding.

But sine it works anyway it does not matter too much for me, the problem is about starting X apps on this box and have the forwarded X11 "output" on another machine.

[Brian Murray (brian-murray)]

I've been unable to recreate this bug when ssh'ing from an Jaunty system using openssh-client version 1:5.1p1-5ubutu1 to a Karmic system with openssh-server version 1:5.1p1-6ubuntu1. Could you please set the LogLevel to DEBUG on the server and include '/var/log/auth.log' with the failure? Additionally what openssh client are you using?

[LGB [Gábor Lénárt] (lgb)]

I unable to reproduce it either, but it was reproducable then. So I suppose this bug is already fixed and/or there was some problem with my config. I set the status to invalid then, if it's OK. Thanks!

[M C (mihaic-gmail)]

I see the same problem, in a repeatable way. I upgraded from 9.04 to 9.10. The ssh server was configured to allow X11 forwarding:

$ cat /etc/ssh/sshd_config | grep X11
X11Forwarding yes
X11UseLocalhost yes
X11DisplayOffset 10

When I connect from another machine using the PuTTY ssh client, I can login just fine, no errors, but the DISPLAY environment variable is not set. The auth_log shows "error: Failed to allocate internet-domain X11 display socket."

Nov 3 18:54:11 localhost sshd[29852]: debug1: Forked child 11013.
Nov 3 18:54:11 localhost sshd[11013]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 3 18:54:11 localhost sshd[11013]: debug1: inetd sockets after dupping: 3, 3
Nov 3 18:54:11 localhost sshd[11013]: Connection from 9.2.19.64 port 16059
Nov 3 18:54:11 localhost sshd[11013]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
Nov 3 18:54:11 localhost sshd[11013]: debug1: no match: PuTTY_Release_0.60
Nov 3 18:54:11 localhost sshd[11013]: debug1: Enabling compatibility mode for protocol 2.0
Nov 3 18:54:11 localhost sshd[11013]: debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
Nov 3 18:54:11 localhost sshd[11013]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Nov 3 18:54:11 localhost sshd[11013]: debug1: SSH2_MSG_KEXINIT sent
Nov 3 18:54:11 localhost sshd[11013]: debug1: SSH2_MSG_KEXINIT received
Nov 3 18:54:11 localhost sshd[11013]: debug1: kex: client->server aes256-ctr hmac-sha1 none
Nov 3 18:54:11 localhost sshd[11013]: debug1: kex: server->client aes256-ctr hmac-sha1 none
Nov 3 18:54:11 localhost sshd[11013]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
Nov 3 18:54:11 localhost sshd[11013]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Nov 3 18:54:11 localhost sshd[11013]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Nov 3 18:54:12 localhost sshd[11013]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Nov 3 18:54:12 localhost sshd[11013]: debug1: SSH2_MSG_NEWKEYS sent
Nov 3 18:54:12 localhost sshd[11013]: debug1: expecting SSH2_MSG_NEWKEYS
Nov 3 18:54:12 localhost sshd[11013]: debug1: SSH2_MSG_NEWKEYS received
Nov 3 18:54:12 localhost sshd[11013]: debug1: KEX done
Nov 3 18:54:12 localhost sshd[11013]: debug1: userauth-request for user USER service ssh-connection method none
Nov 3 18:54:12 localhost sshd[11013]: debug1: attempt 0 failures 0
Nov 3 18:54:12 localhost sshd[11013]: debug1: PAM: initializing for "USER"
Nov 3 18:54:12 localhost sshd[11013]: debug1: PAM: setting PAM_RHOST to "mgebeleizis.watson.ibm.com"
Nov ...

[edvar (edvar-f)]

I'm having the exact same problem after upgrading to Karmic. I've used Ubuntu since Feisty and this is the first time I ever experienced problems with X forwarding on SSH. It worked fine on Jaunty. Basically I'm experiencing the same issues as reported:

$ env | grep DISPLAY
$ echo $DISPLAY
$ xclock
Error: Can't open display:

$ tail /var/log/auth.log
Nov 5 09:34:11 ed-linux sshd[10567]: Accepted password for ed from xx.xx.xx.xx port 47676 ssh2
Nov 5 09:34:11 ed-linux sshd[10567]: pam_unix(sshd:session): session opened for user ed by (uid=0)
Nov 5 09:34:13 ed-linux sshd[10678]: error: Failed to allocate internet-domain X11 display socket.
Nov 5 09:34:21 ed-linux sudo: ed : TTY=pts/0 ; PWD=/home/ed ; USER=root ; COMMAND=/usr/bin/apt-get upgrade
Nov 5 09:35:01 ed-linux CRON[11340]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 5 09:35:01 ed-linux CRON[11340]: pam_unix(cron:session): session closed for user root

$ cat /etc/ssh/sshd_config | grep X11
X11Forwarding yes
X11DisplayOffset 10

[edvar (edvar-f)]

Forgot to mention the loopback address is properly configured on my box:

$ ifconfig lo
lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:139234 errors:0 dropped:0 overruns:0 frame:0
          TX packets:139234 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6975042 (6.9 MB) TX bytes:6975042 (6.9 MB)

I found some links on Google related to the "Failed to allocate internet-domain X11 display socket" error on Solaris machines and they were all related to missing IP configuration on the loopbak interface. So clearly this is not the cause here...

[Henrik Tikanvaara (henrik-tikanvaara)]

I also have this problem. For me it reports the following:

palsa@palsa-eeepc:~$ xeyes
X11 connection rejected because of wrong authentication.
Error: Can't open display: palsa-eeepc:10.0
palsa@palsa-eeepc:~$

[Brian Murray (brian-murray)]

Is everybody using PuTTY as an ssh client? If not it would be quite helpful to know what ssh client and package version with which you are experiencing this bug.

[edvar (edvar-f)]

Yes, I'm using Putty from a Windows box and the same happens on the Terminal app on Mac OS X.
The version of Putty I'm using is 0.60. In regards to SSH on my Karmic box:

$ dpkg -l |grep openssh
ii openssh-client 1:5.1p1-6ubuntu2 secure shell client, an rlogin/rsh/rcp repla
ii openssh-server 1:5.1p1-6ubuntu2 secure shell server, an rshd replacement

[asaijo (asaijo-deactivatedaccount)]

I can fix this problem.
Change /etc/default/ssh/ssh:
SSHD_OPTS=
to
SSHD_OPTS=-4
This lets the ssh-server use onlyq IPv4.
After chaning this setting, you should restart ssh-server:
# /etc/init.d/ssh restart

[edvar (edvar-f)]

It worked!! Many thanks!

[nieproszenieja (mateusz-szulc)]

Same problem here, same entries in auth.log - but I did a clean install of Karmic, this is NOT an upgrade from 9.04.

I can confirm, that workaround from asaijo works (thank you).

[zuhanden (zuhanden)]

asaijo's fix worked great.

This is not the first IPv4-related tweak I've had to perform since upgrading to Karmic. I had to disable IPv6 on my system because DNS queries took 15-30 seconds... and now this.

This fix should be kept available for those who upgraded! Thanks asaijo!!

[Dmitriy Balakin (0x0000.ru)]

I can confirm this ... but this error appeared in the system where IPv6 was disabled in the kernel. In a fresh installation, this error does not occur.

[Mark Schouten (mark-prevented)]

I can confirm this bug. It's on both Karmic and Lucid, no matter which client I use.

See attachments for sshd-debug info on both working and not-working situations, as well as the ssh version info.

[edvar (edvar-f)]

I upgraded to Lucid last weekend and now X Forwarding is not working again:

$ echo $DISPLAY
$ cat /etc/default/ssh |grep OPTS
SSHD_OPTS=-4
$ cat /etc/ssh/sshd_config |grep Forward
X11Forwarding yes

Any ideas?

[edvar (edvar-f)]

Also, same error message on /var/log/auth.log:

May 3 15:59:36 ubuntu sshd[1331]: error: Failed to allocate internet-domain X11 display socket.

[yota (yota-opensystems)]

In Lucid the upstart script /etc/init/ssh.conf does not source /etc/default/ssh, and it seems to be ignoring it on purpose looking at the comment:

# if you used to set SSHD_OPTS in /etc/default/ssh, you can change the
# 'exec' line here instead

the quickfix is to add the "-4" to the exec line in /etc/init/ssh.conf like this:

exec /usr/sbin/sshd -4

But I still feel that ssh.conf *should* source /etc/default/ssh instead...

[Andrew Schulman (andrex)]

Confirmed that this is broken again in Lucid, and I agree with yota: the purpose of /etc/default/* is to provide supported ways for administrators to modify services' behavior without having to modify their startup scripts. It's a regression to stop supporting /etc/default/ssh.

[Andrew Schulman (andrex)]

Also, the revised workaround in #20 does not work for me. I edited /etc/init/ssh.conf as suggested, then ran

initctl reload-configuration
restart ssh

but for some reason the -4 parameter isn't taking effect. ps shows sshd running as just /usr/sbin/sshd with no argument, netstat shows sshd listening on ::::22, and $DISPLAY is still not being set on login. Surely a reboot isn't required?

[Andrew Schulman (andrex)]

Setting

AddressFamily inet

in /etc/ssh/sshd_config and restarting sshd does work around this problem.

[edvar (edvar-f)]

I can confirm adding "AddressFamily inet" to sshd_config fixed the problem for me after a SSH restart:

$ echo $DISPLAY
localhost:10.0

[K. M. Masum Habib (masum-habib)]

Same thing as #24 happened in my case.

[Andrew Schulman (andrex)]

Can anyone else confirm that #20 does not work for them? That is, if you do the following:

* remove "AddressFamily inet" from sshd_config
* add "-4" after "exec /usr/sbin/sshd" in /etc/init/ssh/conf
* run

initctl reload-configuration
restart sshd

then do you still have this problem? Does

pgrep -lf sshd

show just /usr/sbin/sshd, or /usr/sbin/sshd -4?

[yota (yota-opensystems)]

Andrew, in my experience the problem is that restarting a service (i.e. "service ssh restart") does not apply configuration changes.

So please try like this:

initctl reload-configuration
sevice ssh stop
service ssh start

It worked for me (while restart did not work).

[Andrew Schulman (andrex)]

yota, you're correct. stop + start > restart. So #20 does also work for me now. Thanks, Andrew.

[Chris Martin (chris-martin-cc)]

Thanks guys .. this solved mine as well

[Sam Freed (sam-freed)]

Mine is not yet solved, on Lucid. ALso, will you please decide if you want or not the line
AddressFamily inet ??

[Sam Freed (sam-freed)]

bump?

[Sam Freed (sam-freed)]

HAHA! (small dance around)

I found it! Nothing messes modern linux up worse than not having the "loopback" interface configured properly, to 127.0.0.1, also in /etc/hosts.

This is the source of the ODDEST bugs!

[Rene (g.xrc)]

Dear All,
This bug affects me from lucid.
As I don't have ipv6 available, I am used to de-activate it. But this bug still affected me.
I tried the workarounds.
"AddressFamily inet" to sshd_config ........ works for me.
add the "-4" to the exec line in /etc/init/ssh.conf ...... works for me

also it seems that stop, then start is needed for me to apply the new config.

I prefer customize sshd_config, because I always modify it for my personal config, so its just one more line...

[jdobry (jdobry)]

Same for me on 10.04

[Vince McIntyre (vmcintyr)]

This bug affected me on Lucid as well.

$ apt-show-versions |grep ssh
openssh-client/lucid-updates uptodate 1:5.3p1-3ubuntu4
openssh-server/lucid-updates uptodate 1:5.3p1-3ubuntu4
ssh-askpass-gnome/lucid-updates uptodate 1:5.3p1-3ubuntu4

$ grep X11 /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10

The only setting I needed to change was to set SSH_OPTS=-4 in /etc/defaults/ssh
and /etc/init.d/ssh restart.
Then I logged out and logged in again, and
 echo $DISPLAY
 localhost:10

I was connecting from a Mac running OSX 10.6.4 with the stock apple X11 and xterm.

[Vince McIntyre (vmcintyr)]

p.s.
I was able to connect to other servers and tunnel X11 to them, at the same time as I was experiencing this issue with lucid.

$ grep -i family /etc/ssh/sshd_config
$

$ grep 127 /etc/hosts
127.0.0.1 localhost
127.0.1.1 ubuntu

$ ifconfig lo
lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:297 errors:0 dropped:0 overruns:0 frame:0
          TX packets:297 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:80576 (80.5 KB) TX bytes:80576 (80.5 KB)

[Rush Tonop Online (rush-online)]

My case:

# Go to workstation
rush@laptop:~$ ssh -X workstation

# Check for $DISPLAY
rush@workstation:~$ env | grep DISPLAY || echo "No display found"
No display found

# Check log
workstation:~$ sudo -s
workstation:~# grep X11 /var/log/auth.log
Sep 23 16:33:10 workstation sshd[14105]: error: Failed to allocate internet-domain X11 display socket.

# Yes, it is!

# Check ipv6 suppport
root@workstation:~# sysctl net.ipv6.conf.all.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1

# It's the answer.
# Now we must disable ipv6 support in sshd too:
root@workstation:~# sed -i 's|^exec /usr/sbin/sshd$|exec /usr/sbin/sshd -4|g' /etc/init/ssh.conf
root@workstation:~# service ssh restart
root@workstation:~# exit
rush@workstation:~$ exit

# Check changes
rush@laptop:~$ ssh -X workstation

# Check for $DISPLAY
rush@workstation:~$ env | grep DISPLAY || echo "No display found"
DISPLAY=localhost:10.0

Done.

[Ryan Daly (daly-ctcnet)]

I also see this bug when using 10.04.4.

The fix for me was adding "AddressFamily inet" to the sshd_config file.