Thank you for the bug report. It would be great if this would be working out of the box correcly.

I did some digging in the history and there were already requests to do something like this years ago (see bug #484171, which asked for dbus forwarding, even with a proof of concept). For security reasons, I do not think it is a good idea to share the whole dbus with the potentially untrusted server so I believe starting the new session dbus should be preferred here.

The question is when should it happen and what application should take care of that. I do not think this should be hardcoded in the OpenSSH, since we have other ways to customize what is running upon the ssh login.

The DBUS_SESSION_BUS_ADDRESS is set by the pam_systemd to current local user session bus, which is what one usually wants when opening a new terminal locally. But usually not what you want when connecting remotely. I will ask around the desktop/gnome/systemd developers if they have some ideas how this can be solved.

Yet I reckon that has nothing to do with DBUS actually, but with gtk+ forcing Wayland display
to "wayland-0" if no WAYLAND_DISPLAY is set.

To force the remote gtk+ apps to use X11 tunnelling via ssh (instead of Wayland), use GDK_BACKEND=x11, e.g.:

1. $ ssh -Y remotehost
2. $ GDK_BACKEND=x11 gnome-calculator → ends up on "local" X11 display

Also, please note that gnome-terminal is a bit of a special case here, because it is indeed running a daemon (gnome-terminal-server) which takes care of opening multiple terminal windows from the same process, so even with forcing X11, the window will still open on the remote host (unless a new instance of gnome-terminal-server is started locally).

E.g.:

1. $ ssh -Y remotehost
2. $ GDK_BACKEND=x11 /usr/libexec/gnome-terminal-server --app-id my.remote.Terminal &
3. $ GDK_BACKEND=x11 gnome-terminal --app-id my.remote.Terminal

I don't think Olivier Fourdan's assessment is accurate for my case; setting GDK_BACKEND does not appear to affect the symptom for me. "ssh -X -Y beta@beta0 GDK_BACKEND=x11 eog" produces the same 25-second delay and segfault in xdg-desktop-portal (when the user is not also logged into the console) as without the variable.

I don't know whether this is relevant, but my RHEL8 Beta installation is installed on a Hyper-V virtual machine, and the console is running Xorg, not Wayland (I'm guessing because Wayland doesn't support the emulated video card, but that's not necessarily relevant to this bug; the point is that Wayland does not appear to be in the picture).

Starting gnome-terminal-server does cause gnome-terminal to appear on the correct server, but there's still the same 25-second delay.  GDK_BACKEND is also irrelevant to the behaviour for that case.

I agree that forwarding dbus through the SSH connection doesn't feel like the right solution: among other concerns, I don't know whether it's reasonable to assume that the SSH client's system is running DBUS, let alone a compatible instance. 

I recognize that this may not strictly be an openssh issue, and I appreciate you reaching out to the other subsystem developers.  My impression was that dbus instances were intended to be per-session, not per-user, but I'm not up to date on current design criteria.

Try setting "NO_AT_BRIDGE=1" as well, does it help with the 25 seconds delay?

Setting NO_AT_BRIDGE=1 also has no effect.

I strongly suspect that there is a connection between the delay and the fact that xdg-desktop-portal is segfaulting: during one instance, journalctl reported, e.g.:

Mar 15 10:51:06 beta0.ecf.utoronto.ca systemd[6729]: Starting Portal service (GTK+/GNOME implementation)...
Mar 15 10:51:06 beta0.ecf.utoronto.ca xdg-desktop-portal-gtk[6913]: Unable to init server: Could not connect: Connection refused
Mar 15 10:51:06 beta0.ecf.utoronto.ca xdg-desktop-por[6913]: cannot open display: 
Mar 15 10:51:06 beta0.ecf.utoronto.ca systemd[6729]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
Mar 15 10:51:06 beta0.ecf.utoronto.ca systemd[6729]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
Mar 15 10:51:06 beta0.ecf.utoronto.ca systemd[6729]: Failed to start Portal service (GTK+/GNOME implementation).
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por[6895]: Failed to create file chooser proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por[6895]: g_dbus_interface_skeleton_set_flags: assertion 'G_IS_DBUS_INTERFACE_SKELETON (interface_)' failed
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por[6895]: invalid (NULL) pointer instance
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por[6895]: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por[6895]: g_dbus_interface_skeleton_export: assertion 'G_IS_DBUS_INTERFACE_SKELETON (interface_)' failed

I can provide more detailed logs if you are unable to reproduce the issue yourself, but I think this is tangential to the actual problem--the crashing of xdg-desktop-portal looks like a symptom rather than a cause, as it is trying to connect to a nonexistent X server associated with the dbus instance.  Note that the delay goes away if the same user is logged into the console via X, since the application can connect to the xdg-desktop-portal service (for the wrong X server instance), but this fact is not useful as a mitigation.

(In reply to Jakub Jelen from comment #1)
> The DBUS_SESSION_BUS_ADDRESS is set by the pam_systemd to current local user
> session bus, which is what one usually wants when opening a new terminal
> locally. But usually not what you want when connecting remotely. I will ask
> around the desktop/gnome/systemd developers if they have some ideas how this
> can be solved.

Well connecting remotely isn't really the relevant factor, it's whether or
not remote display forwarding is enabled.

I mean I actually would want it to use the local bus and local display if
i'm not trying to forward the app to another machine.

Probably pam_systemd shouldn't set DBUS_SESSION_BUS_ADDRESS if it's a remote
connection and if DISPLAY is in the environment.

But that's not sufficient to fix the problem since glib and i guess libdbus
both will just use the well known name of the user bus if DBUS_SESSION_BUS_ADDRESS
isn't set.

So I think I agree, a fresh bus should get started, and DBUS_SESSION_BUS_ADDRESS should
get set, if openssh is doing remote display forwarding.

(In reply to Ray Strode [halfline] from comment #7)
> Well connecting remotely isn't really the relevant factor, it's whether or
> not remote display forwarding is enabled.
> 
> I mean I actually would want it to use the local bus and local display if
> i'm not trying to forward the app to another machine.

I do not think either option is to use local dbus. It will always be a remote dbus,
but in one case it will be the default and in the other dedicated session dbus.

> Probably pam_systemd shouldn't set DBUS_SESSION_BUS_ADDRESS if it's a remote
> connection and if DISPLAY is in the environment.

I am not sure whether the DISPLAY environment variable is propagated to the pam_systemd.
If I am right, it is set only to the executed process, but pam is running in separate
thread, which might limit the pam_systemd decission options.

> But that's not sufficient to fix the problem since glib and i guess libdbus
> both will just use the well known name of the user bus if
> DBUS_SESSION_BUS_ADDRESS
> isn't set.
> 
> So I think I agree, a fresh bus should get started, and
> DBUS_SESSION_BUS_ADDRESS should
> get set, if openssh is doing remote display forwarding.

Lets see what is the systemd developers take on this.

to be clear, i meant "local to the app" not "local to the operator". poor word choice, indeed, but the crux of my point is if the display is forwarded, there should be a isolated message bus, imo. if the display is not forwarded, the app should use the user bus.

i dont think pam_systemd should be the thing starting the isolated bus mind you, but i'll let the systemd guys chime in.