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.
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.
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/
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.
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.
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.
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
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.
(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
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.
(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. 😀
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.
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.
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.
Thank you very much for taking care of this. I will change the close status to next release to reflect this.