X11 forwarding over ssh only working with sudo

Question

Problem

I'm unable to get X11 forwarding over ssh working as a normal user anymore. It worked a few months ago, so something has been inadvertently changed.

What I've tried

Works with sudo:

As far as I can tell, my ssh and sshd configs are correct. In fact, X11 is correctly forwarded if I run as root with sudo:

$ ssh -X lm@<ip> -i <key>

lm@localhost:~$ xeyes
Error: Can't open display: localhost:10.0

lm@localhost:~$ sudo xeyes

lm@localhost:~$

Successfully forwarding X with sudo seems to be a common issue, but this is the opposite problem. I don't really understand the info I've seen about X forwarding as root or another user, and I don't need to forward as root or another user at all anyways. So, how can I reset this back to normal?

xauth

It would make sense to me that this is an auth issue. I'm not sure how to tell if it is correct or not, though.

There are two entries in the user's .Xauthority

lm@localhost:~$ xauth info
Authority file:       /home/lm/.Xauthority
File new:             no
File locked:          no
Number of entries:    2
Changes honored:      yes
Changes made:         no
Current input:        (argv):1

lm@localhost:~$ xauth list
edare-fmt17138762/unix:10  MIT-MAGIC-COOKIE-1  48081e511d8ba861ccaf146b73a01617
localhost/unix:10  MIT-MAGIC-COOKIE-1  ce23a352c8f10814e103474aa620fc31

I tried removing .Xauthority but that didn't solve the issue.

Potentially related hostname issues

The hostname should be edare-fmt17138762, but that is resetting every reboot. I've tried setting the hostname again, and also fully resetting the hostname to localhost, but neither of those had any effect on forwarding X, so it doesn't seem like the hostname specifically is the issue.

sshd_config changes

I tried using X11UseLocalhost yes with no effect.

I also tried X11UseLocalhost no, which gives additional and slightly different errors:

$ ssh -Y [email protected] -i <key>
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-93-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
Last login: Thu Mar  1 14:51:41 2018 from 192.168.0.2
/usr/bin/xauth: (stdin):1:  bad display name "edare-fmt17138762:10.0" in "remove" command
/usr/bin/xauth: (stdin):2:  bad display name "edare-fmt17138762:10.0" in "add" command
lm@edare-fmt17138762:~$ xeyes
Error: Can't open display: edare-fmt17138762:10.0

setting DISPLAY

I also tried setting the DISPLAY variable to 127.0.0.1:10.0:

lm@edare-fmt17138762:~$ export DISPLAY='192.168.0.15:10.0'
lm@edare-fmt17138762:~$ xeyes
X11 connection rejected because of wrong authentication.
Error: Can't open display: 192.168.0.15:12.0

SSH Config

server

Ubuntu 16.04 running standard OpenSSH.

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
    PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
    PasswordAuthentication no

clients

The issue is the same from several clients that, again, used to work: OpenSSH from another Ubuntu 16.04 machine and puTTy from Windows 10.

ssh -v

OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.15 [192.168.0.15] port 22.
debug1: Connection established.
debug1: identity file <my file> type 1
debug1: key_load_public: No such file or directory
debug1: identity file <my file> type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.15:22 as 'lm'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:WVq6hBhuqXF99QGeoyfeiLYk+l7fJOGqpyk52roqdcE
debug1: Host '192.168.0.15' is known and matches the ECDSA host key.
debug1: Found key in /home/jmilloy/.ssh/known_hosts:34
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: <my key>
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.0.15 ([192.168.0.15]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-93-generic x86_64)

Solution 1

/etc/hosts has to be readable. My /etc/hosts permissions were -rw-r-----, and changing to -rw-r--r-- fixed the issue.

Solution 2

Regarding the hostname resetting, check if you have something like cloud-config installed and configured. It really messes up some stuff, you probably need to change some option like update_hostname or set_hostname.

Regarding the question, try adding the following to your sshd_config and restarting sshd.

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AddressFamily inet

Comments

[FooBee]

Please add information about your SSH config, how you established the connection etc.,

[jmilloy]

Okay, thanks, I fleshed that out. What else should I include?

[jmilloy]

Those configs didn't help. I couldn't find any cloud-configs anywhere. How can I be sure? It's just a fairly vanilla Ubuntu 16.04 server, with X installed.

[Gothrek]

do ssh -v lm@<ip> -i <key>, it should tell you what you're missing as part of the pre connection setup.

[jmilloy]

I added the output from that... the only message related to X11 is debug1: Requesting X11 forwarding with authentication spoofing.

[jmilloy]

With more verbose logging, I see debug2: X11 forwarding request accepted on channel 0.

[Gothrek]

The only thing left to check are security logs and dmesg or selinux. If nothing's there, then I've no idea :)

[Gothrek]

Also if DISPLAY env var is not setting on the server, that might mean that on the client, there is no x window manager running.

[jmilloy]

I just want to emphasize that it is working with sudo; so it doesn't seem like a client side issue.

[Gothrek]

Yeah and that's the weird part.