Bug 1425250 - Gnome with wayland: ssh -X: Warning: No xauth data; using fake authentication data for X11 forwarding.
Summary: Gnome with wayland: ssh -X: Warning: No xauth data; using fake authentication...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 25
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Jakub Jelen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-21 00:23 UTC by Edgar Hoch
Modified: 2019-06-24 08:56 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1949176 (view as bug list)
Environment:
Last Closed: 2017-12-12 10:13:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Edgar Hoch 2017-02-21 00:23:19 UTC
Description of problem:

When logged in using default desktop sesseion GNOME with Wayland, then ssh client prints the warning listed below when X11 forwarding is enabled. This does not happen when using a desktop session which uses Xorg as display server, for example with GNOME with Xorg or Cinnemon.

I use explicit options in the following example instead of "-X" to show which options I had set in /etc/ssh/ssh_config.d/61-myoptions.conf.

$ ssh -o ForwardX11=yes -o ForwardAgent=yes anotherhost
Warning: No xauth data; using fake authentication data for X11 forwarding.
...


Version-Release number of selected component (if applicable):
Fedora 25 x86_64 with all updates

openssh-7.4p1-2.fc25.x86_64

kernel-4.9.9-200.fc25.x86_64
gnome-session-wayland-session-3.22.2-3.fc25.x86_64
gnome-session-xsession-3.22.2-3.fc25.x86_64
gnome-session-3.22.2-3.fc25.x86_64
gnome-common-3.18.0-2.fc24.noarch
xorg-x11-server-Xwayland-1.19.1-3.fc25.x86_64
libwayland-server-1.12.0-1.fc25.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Log in on a desktop system with wayland as display server, for example GNOME
2. Start a ssh connection with
   ssh -o ForwardX11=yes -o ForwardAgent=yes anotherhost
3. Log out and log in again with a desktop system which uses Xorg as display server, for example GNOME with Xorg
4. Start a ssh connection with
   ssh -o ForwardX11=yes -o ForwardAgent=yes anotherhost


Actual results:
Step 2: ssh prints a warning message:
Warning: No xauth data; using fake authentication data for X11 forwarding.

Step 4: ssh prints no warning message.

Expected results:
Step 2: ssh prints no warning message.
Step 4: ssh prints no warning message.

Additional info:
I didn't find the reason for this error message.
Because my ssh configuration works fine with Xorg but not with Xwayland, there seems to be an incompatibility between these display server.

The warning is not only vexing but may break some scripts that do remote command execution and scans the output of the executed commands.

I have assigned this bug report to openssh because his program prints the error. But it may be that the reason is in wayland and wayland should implement some features that are available in Xorg but not in Xwayland. Please feel free to assign to another component which may be more suitable for this problem.

Comment 1 Edgar Hoch 2017-02-21 00:29:47 UTC
Oh, I have forgotten to say that X11 forwarding works on Xwayland and Xorg (at least in my tests), the difference is the warning message.

I don't know if the cause of the warning causes any functional limitations.

Comment 2 Jakub Jelen 2017-03-27 16:24:33 UTC
Yes, Wayland is not compatible with X11 and one of the things they are trying to achieve is a security (therefore no random processes touching all your desktop).

The XWayland is somewhere in the middle talking with both parts, native Wayland and X11 server running above it [1]. If I understand well, the target is WOW [2], but we are certainly not there yet.

Can you provide the debug log from client and server to see the context of the messages? I will try to have a look into that myself, but that error message will most probably be there for some reason.

I was trying to search around if there is any update on that (so far I heard only that it does not work) but I didn't find any reasonable update.

[1] https://wayland.freedesktop.org/xserver.html
[2] https://blogs.s-osg.org/wow-wayland-over-wire/

Comment 3 mathew 2017-05-10 18:22:12 UTC
Not the original reporter, but I'm having the same problem connecting to Debian Stable. Here's a client debug log:

% ssh -vvv -X castor.local
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /home/meta/.ssh/config
debug1: /home/meta/.ssh/config line 7: Applying options for castor.local
debug3: kex names ok: [curve25519-sha256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1]
debug3: kex names ok: [curve25519-sha256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1]
debug1: /home/meta/.ssh/config line 46: Applying options for *
debug3: kex names ok: [curve25519-sha256,diffie-hellman-group-exchange-sha256]
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 70: Applying options for *
debug1: /etc/ssh/ssh_config line 81: Deprecated option "useroaming"
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/meta/.ssh/control-meta:22" does not exist
debug2: resolving "castor.local" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to castor.local [2605:a601:1117:8800:1278:d2ff:feab:cd52] port 22.
debug1: Connection established.
debug1: identity file /home/meta/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/meta/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/meta/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/meta/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/meta/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/meta/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/meta/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/meta/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to castor.local:22 as 'meta'
debug3: hostkeys_foreach: reading file "/home/meta/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/meta/.ssh/known_hosts:85
debug3: load_hostkeys: loaded 1 keys from castor.local
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,diffie-hellman-group-exchange-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01,ssh-rsa-cert-v01,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib,zlib
debug2: compression stoc: none,zlib,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,chacha20-poly1305
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,chacha20-poly1305
debug2: MACs ctos: umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib
debug2: compression stoc: none,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305 MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305 MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:KXu6fGXx4mtpkvgSDvYRR3QhIc8j/DGOxkv3OqzYCbo
debug3: hostkeys_foreach: reading file "/home/meta/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/meta/.ssh/known_hosts:85
debug3: load_hostkeys: loaded 1 keys from castor.local
debug3: hostkeys_foreach: reading file "/home/meta/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/meta/.ssh/known_hosts:137
debug3: load_hostkeys: loaded 1 keys from 2605:a601:1117:8800:1278:d2ff:feab:cd52
debug1: Host 'castor.local' is known and matches the ECDSA host key.
debug1: Found key in /home/meta/.ssh/known_hosts:85
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /home/meta/.ssh/id_rsa (0x556619b3f640)
debug2: key: /home/meta/.ssh/id_dsa ((nil))
debug2: key: /home/meta/.ssh/id_ecdsa ((nil))
debug2: key: /home/meta/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/meta/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:FqCWz7o6AacfNwPmWJoT85pPMIjDPlbY5u7t3a5A1pU
debug3: sign_and_send_pubkey: RSA SHA256:FqCWz7o6AacfNwPmWJoT85pPMIjDPlbY5u7t3a5A1pU
Enter passphrase for key '/home/meta/.ssh/id_rsa': 
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to castor.local ([2605:a601:1117:8800:1278:d2ff:feab:cd52]:22).
debug1: setting up multiplex master socket
debug3: muxserver_listen: temporary control path /home/meta/.ssh/control-meta:22.LeukrthR62Sogv2v
debug2: fd 4 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: channel 0: new [/home/meta/.ssh/control-meta:22]
debug3: muxserver_listen: mux listener channel 0 fd 4
debug1: channel 1: new [client-session]
debug3: ssh_session2_open: channel_new: 1
debug2: channel 1: send open
debug3: send packet: type 90
debug1: Entering interactive session.
debug1: pledge: id
debug3: receive packet: type 91
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 1: request x11-req confirm 1
debug3: send packet: type 98
debug1: Requesting authentication agent forwarding.
debug2: channel 1: request auth-agent-req confirm 0
debug3: send packet: type 98
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IPV6_TCLASS 0x10
debug2: client_session2_setup: id 1
debug2: channel 1: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env USER
debug1: Sending env XMODIFIERS = @im=ibus
debug2: channel 1: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 1: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env DISPLAY
debug3: Ignored env SHLVL
debug3: Ignored env LOGNAME
debug1: Sending env LC_CTYPE = en_US.UTF-8
debug2: channel 1: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env CVS_RSH
debug3: Ignored env XDG_VTNR
debug1: Sending env LC_ALL = en_US.UTF-8
debug2: channel 1: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env PWD
debug3: Ignored env QT_QPA_PLATFORMTHEME
debug3: Ignored env JOURNAL_STREAM
debug3: Ignored env QTDIR
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env RBENV_SHELL
debug3: Ignored env GOPATH
debug3: Ignored env XDG_SESSION_DESKTOP
debug3: Ignored env GDMSESSION
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env USERNAME
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env WAYLAND_DISPLAY
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env MODULESHOME
debug3: Ignored env HISTCONTROL
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env GJS_DEBUG_TOPICS
debug3: Ignored env MAIL
debug3: Ignored env COLORTERM
debug3: Ignored env LESSOPEN
debug3: Ignored env XDG_MENU_PREFIX
debug3: Ignored env GDM_LANG
debug3: Ignored env HOSTNAME
debug3: Ignored env TIME_STYLE
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env GJS_DEBUG_OUTPUT
debug3: Ignored env TERM
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env HISTSIZE
debug3: Ignored env PATH
debug3: Ignored env KDEDIRS
debug3: Ignored env QTLIB
debug3: Ignored env HOME
debug3: Ignored env MODULEPATH
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env QTINC
debug3: Ignored env SSH_ASKPASS
debug3: Ignored env XDG_SEAT
debug3: Ignored env VTE_VERSION
debug3: Ignored env LOADEDMODULES
debug3: Ignored env OLDPWD
debug3: Ignored env LS_COLORS
debug3: Ignored env KEYTIMEOUT
debug3: Ignored env LESS
debug3: Ignored env LESSCHARSET
debug3: Ignored env EDITOR
debug3: Ignored env VISUAL
debug3: Ignored env PS_PERSONALITY
debug3: Ignored env PDSH_RCMD_TYPE
debug3: Ignored env HTML_TIDY
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env OSFONTDIR
debug3: Ignored env INFOPATH
debug3: Ignored env MANPATH
debug3: Ignored env ECLIPSELINK_HOME
debug3: Ignored env DRIVER_CLASSPATH
debug3: Ignored env GOROOT
debug3: Ignored env CGO_CFLAGS
debug3: Ignored env _
debug2: channel 1: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 1: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 1
debug2: X11 forwarding request accepted on channel 1
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 1
debug2: PTY allocation request accepted on channel 1
debug2: channel 1: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 1
debug2: shell request accepted on channel 1

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed May 10 13:14:01 2017 from 2605:a601:1117:8800:8251:32a3:e097:5176
Agent pid 18862

Here's the server-side log:

May 10 13:17:53 castor sshd[18773]: Set /proc/self/oom_score_adj from 0 to -1000
May 10 13:17:53 castor sshd[18773]: debug1: Bind to port 22 on 0.0.0.0.
May 10 13:17:53 castor sshd[18773]: Server listening on 0.0.0.0 port 22.
May 10 13:17:53 castor sshd[18773]: debug1: Bind to port 22 on ::.
May 10 13:17:53 castor sshd[18773]: Server listening on :: port 22.
May 10 13:18:04 castor sshd[18773]: debug1: Forked child 18785.
May 10 13:18:04 castor sshd[18785]: Set /proc/self/oom_score_adj to 0
May 10 13:18:04 castor sshd[18785]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
May 10 13:18:04 castor sshd[18785]: debug1: inetd sockets after dupping: 3, 3
May 10 13:18:04 castor sshd[18785]: Connection from 2605:a601:1117:8800:8251:32a3:e097:5176 port 55538 on 2605:a601:1117:8800:1278:d2ff:feab:cd52 port 22
May 10 13:18:04 castor sshd[18785]: debug1: Client protocol version 2.0; client software version OpenSSH_7.4
May 10 13:18:04 castor sshd[18785]: debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
May 10 13:18:04 castor sshd[18785]: debug1: Enabling compatibility mode for protocol 2.0
May 10 13:18:04 castor sshd[18785]: debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
May 10 13:18:04 castor sshd[18785]: debug1: permanently_set_uid: 107/65534 [preauth]
May 10 13:18:04 castor sshd[18785]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
May 10 13:18:04 castor sshd[18785]: debug1: SSH2_MSG_KEXINIT sent [preauth]
May 10 13:18:04 castor sshd[18785]: debug1: SSH2_MSG_KEXINIT received [preauth]
May 10 13:18:04 castor sshd[18785]: debug1: kex: client->server chacha20-poly1305 <implicit> none [preauth]
May 10 13:18:04 castor sshd[18785]: debug1: kex: server->client chacha20-poly1305 <implicit> none [preauth]
May 10 13:18:04 castor sshd[18785]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
May 10 13:18:05 castor sshd[18785]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
May 10 13:18:05 castor sshd[18785]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
May 10 13:18:05 castor sshd[18785]: debug1: SSH2_MSG_NEWKEYS received [preauth]
May 10 13:18:05 castor sshd[18785]: debug1: KEX done [preauth]
May 10 13:18:05 castor sshd[18785]: debug1: userauth-request for user meta service ssh-connection method none [preauth]
May 10 13:18:05 castor sshd[18785]: debug1: attempt 0 failures 0 [preauth]
May 10 13:18:06 castor sshd[18785]: debug1: PAM: initializing for "meta"
May 10 13:18:06 castor sshd[18785]: debug1: PAM: setting PAM_RHOST to "2605:a601:1117:8800:8251:32a3:e097:5176"
May 10 13:18:06 castor sshd[18785]: debug1: PAM: setting PAM_TTY to "ssh"
May 10 13:18:06 castor sshd[18785]: debug1: userauth-request for user meta service ssh-connection method publickey [preauth]
May 10 13:18:06 castor sshd[18785]: debug1: attempt 1 failures 0 [preauth]
May 10 13:18:06 castor sshd[18785]: debug1: test whether pkalg/pkblob are acceptable [preauth]
May 10 13:18:06 castor sshd[18785]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
May 10 13:18:06 castor sshd[18785]: debug1: trying public key file /home/meta/.ssh/authorized_keys
May 10 13:18:06 castor sshd[18785]: debug1: fd 4 clearing O_NONBLOCK
May 10 13:18:06 castor sshd[18785]: debug1: matching key found: file /home/meta/.ssh/authorized_keys, line 2 RSA e5:2c:d4:f8:4f:63:c3:ab:e7:ac:10:5e:84:ee:40:60
May 10 13:18:06 castor sshd[18785]: debug1: restore_uid: 0/0
May 10 13:18:06 castor sshd[18785]: Postponed publickey for meta from 2605:a601:1117:8800:8251:32a3:e097:5176 port 55538 ssh2 [preauth]
May 10 13:18:09 castor sshd[18785]: debug1: userauth-request for user meta service ssh-connection method publickey [preauth]
May 10 13:18:09 castor sshd[18785]: debug1: attempt 2 failures 0 [preauth]
May 10 13:18:09 castor sshd[18785]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
May 10 13:18:09 castor sshd[18785]: debug1: trying public key file /home/meta/.ssh/authorized_keys
May 10 13:18:09 castor sshd[18785]: debug1: fd 4 clearing O_NONBLOCK
May 10 13:18:09 castor sshd[18785]: debug1: matching key found: file /home/meta/.ssh/authorized_keys, line 2 RSA e5:2c:d4:f8:4f:63:c3:ab:e7:ac:10:5e:84:ee:40:60
May 10 13:18:09 castor sshd[18785]: debug1: restore_uid: 0/0
May 10 13:18:09 castor sshd[18785]: debug1: do_pam_account: called
May 10 13:18:09 castor sshd[18785]: Accepted publickey for meta from 2605:a601:1117:8800:8251:32a3:e097:5176 port 55538 ssh2: RSA e5:2c:d4:f8:4f:63:c3:ab:e7:ac:10:5e:84:ee:40:60
May 10 13:18:09 castor sshd[18785]: debug1: monitor_child_preauth: meta has been authenticated by privileged process
May 10 13:18:09 castor sshd[18785]: debug1: monitor_read_log: child log fd closed
May 10 13:18:09 castor sshd[18785]: debug1: PAM: establishing credentials
May 10 13:18:09 castor sshd[18785]: pam_unix(sshd:session): session opened for user meta by (uid=0)
May 10 13:18:09 castor sshd[18785]: User child is on pid 18793
May 10 13:18:09 castor sshd[18793]: debug1: SELinux support disabled
May 10 13:18:09 castor sshd[18793]: debug1: PAM: establishing credentials
May 10 13:18:09 castor sshd[18793]: debug1: permanently_set_uid: 1000/1000
May 10 13:18:09 castor sshd[18793]: debug1: packet_set_postauth: called
May 10 13:18:09 castor sshd[18793]: debug1: Entering interactive session for SSH2.
May 10 13:18:09 castor sshd[18793]: debug1: server_init_dispatch_20
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_open: ctype session rchan 1 win 1048576 max 16384
May 10 13:18:09 castor sshd[18793]: debug1: input_session_request
May 10 13:18:09 castor sshd[18793]: debug1: channel 0: new [server-session]
May 10 13:18:09 castor sshd[18793]: debug1: session_new: session 0
May 10 13:18:09 castor sshd[18793]: debug1: session_open: channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_open: session 0: link with channel 0
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_open: confirm session
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_req: channel 0 request x11-req reply 1
May 10 13:18:09 castor sshd[18793]: debug1: session_by_channel: session 0 channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_input_channel_req: session 0 req x11-req
May 10 13:18:09 castor sshd[18793]: debug1: channel 1: new [X11 inet listener]
May 10 13:18:09 castor sshd[18793]: debug1: channel 2: new [X11 inet listener]
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_req: channel 0 request auth-agent-req reply 0
May 10 13:18:09 castor sshd[18793]: debug1: session_by_channel: session 0 channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_input_channel_req: session 0 req auth-agent-req
May 10 13:18:09 castor sshd[18793]: debug1: temporarily_use_uid: 1000/1000 (e=1000/1000)
May 10 13:18:09 castor sshd[18793]: debug1: restore_uid: (unprivileged)
May 10 13:18:09 castor sshd[18793]: debug1: channel 3: new [auth socket]
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
May 10 13:18:09 castor sshd[18793]: debug1: session_by_channel: session 0 channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_input_channel_req: session 0 req pty-req
May 10 13:18:09 castor sshd[18793]: debug1: Allocating pty.
May 10 13:18:09 castor sshd[18785]: debug1: session_new: session 0
May 10 13:18:09 castor sshd[18785]: debug1: SELinux support disabled
May 10 13:18:09 castor sshd[18793]: debug1: session_pty_req: session 0 alloc /dev/pts/0
May 10 13:18:09 castor sshd[18793]: debug1: Ignoring unsupported tty mode opcode 42 (0x2a)
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_req: channel 0 request env reply 0
May 10 13:18:09 castor sshd[18793]: debug1: session_by_channel: session 0 channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_input_channel_req: session 0 req env
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_req: channel 0 request env reply 0
May 10 13:18:09 castor sshd[18793]: debug1: session_by_channel: session 0 channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_input_channel_req: session 0 req env
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_req: channel 0 request env reply 0
May 10 13:18:09 castor sshd[18793]: debug1: session_by_channel: session 0 channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_input_channel_req: session 0 req env
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_req: channel 0 request env reply 0
May 10 13:18:09 castor sshd[18793]: debug1: session_by_channel: session 0 channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_input_channel_req: session 0 req env
May 10 13:18:09 castor sshd[18793]: debug1: server_input_channel_req: channel 0 request shell reply 1
May 10 13:18:09 castor sshd[18793]: debug1: session_by_channel: session 0 channel 0
May 10 13:18:09 castor sshd[18793]: debug1: session_input_channel_req: session 0 req shell
May 10 13:18:09 castor sshd[18793]: Starting session: shell on pts/0 for meta from 2605:a601:1117:8800:8251:32a3:e097:5176 port 55538
May 10 13:18:09 castor sshd[18794]: debug1: Setting controlling tty using TIOCSCTTY.

Comment 4 XU Guang-zhao 2017-06-09 05:01:55 UTC
Seems that Xwayland uses host based authentication, while ordinary X server uses cookie based authentication. Therefore xauth is unusable under Xwayland but only xhost, and ~/.Xauthority is missing. I wonder whether Xwayland can be switched to cookie based authentication, by configuration.

Comment 5 XU Guang-zhao 2017-06-09 05:05:08 UTC
Additionally, [X SECURITY Extension](https://www.x.org/releases/X11R7.6/doc/xextproto/security.html) seems to be missing too under the default Fedora installation and Xwayland.

Comment 6 XU Guang-zhao 2017-06-18 02:02:29 UTC
Well, as explained in Section 4.3.11 of the Security Guide [1], the X SECURITY Extension is actually disabled. But can we re-enable it? Although "Red Hat recommends not using X11 forwarding while connecting to untrusted hosts", it provides some sense of security than none.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Security_Guide/sec-Securing_Services.html#sec-Securing_SSH

Comment 7 Jakub Jelen 2017-09-20 09:59:44 UTC
Sorry for a late reply. To my understanding a problem is that Fedora does not provide or generate the .Xauthority files in the users home directories (they are not needed for the graphical sessions anymore, since we are using Wayland). You can verify that by the following command:

    $ xauth list :0
    xauth:  file /home/jjelen/.Xauthority does not exist

In this case, the warning message makes sense since the SSH is doing something else than might be expected by user.

Though it might be a problem for scripts, the scripts can ignore this message by setting -q so I don't see any immediate action needed in this case. But I will leave this bug open for some time for the record for others.

Comment 8 XU Guang-zhao 2017-09-20 13:13:13 UTC
(In reply to Jakub Jelen from comment #7)
> Sorry for a late reply. To my understanding a problem is that Fedora does
> not provide or generate the .Xauthority files in the users home directories
> (they are not needed for the graphical sessions anymore, since we are using
> Wayland). You can verify that by the following command:
> 
>     $ xauth list :0
>     xauth:  file /home/jjelen/.Xauthority does not exist
> 
> In this case, the warning message makes sense since the SSH is doing
> something else than might be expected by user.
> 
> Though it might be a problem for scripts, the scripts can ignore this
> message by setting -q so I don't see any immediate action needed in this
> case. But I will leave this bug open for some time for the record for others.

Well is this a security issue when remote application get full permission on the local host, without the X SECURITY Extension? Thanks

Comment 9 Jakub Jelen 2017-09-20 13:55:34 UTC
The security extension is different topic than started in the description of this bugzilla. But to your question:

> Well is this a security issue when remote application get full permission on the local host, without the X SECURITY Extension? Thanks

 * The security extension was disabled in Xorg for years in favor of XACE
 * You are using Wayland and your applications are running in Wayland, the XWayland or whatever transition mechanism should prevent remote applications to get full access to your desktop.
 * You should really not connect with X11 forwarding to the hosts you do not trust.

Comment 10 XU Guang-zhao 2017-09-21 00:21:56 UTC
(In reply to Jakub Jelen from comment #9)
> The security extension is different topic than started in the description of
> this bugzilla. But to your question:
> 
> > Well is this a security issue when remote application get full permission on the local host, without the X SECURITY Extension? Thanks
> 
>  * The security extension was disabled in Xorg for years in favor of XACE
>  * You are using Wayland and your applications are running in Wayland, the
> XWayland or whatever transition mechanism should prevent remote applications
> to get full access to your desktop.
>  * You should really not connect with X11 forwarding to the hosts you do not
> trust.

Thanks for your information. Actually I am not going to connect to any untrusted hosts, but just to find a way to isolate untrusted GUI applications running locally. My applications are running in XWayland not Wayland, so untrusted Windows applications running inside wine probably have means to log my key input in my Chromium browser. XACE replaced X SECURITY Extension but seemingly some features are missing. Fortunately, according to https://fedoraproject.org/wiki/Changes/WorkstationOstree there is an effort to make per-app xwayland possible for X apps. 😀

Comment 11 Fedora End Of Life 2017-11-16 19:00:38 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 12 Fedora End Of Life 2017-12-12 10:13:49 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 13 Hans de Goede 2019-06-24 08:12:40 UTC
I've submitted a merge-req for mutter to generate and pass an xauth file to Xwayland when starting it:
https://gitlab.gnome.org/GNOME/mutter/merge_requests/626

This has been accepted:
https://gitlab.gnome.org/GNOME/mutter/commit/a8984a81c2e887623d69ec9989ae8a5025f7bd47

So starting with GNOME-3.34 there will be a xauth file and then ssh -X should no longer give the "Warning: No xauth data" message.

Comment 14 Jakub Jelen 2019-06-24 08:56:01 UTC
Thank you very much for taking care of this. I will change the close status to next release to reflect this.


Note You need to log in before you can comment on or make changes to this bug.