Hello,
Theoretically yes it could work, but nothing was made to make it easy so
far. At-spi listens on a dbus bus which is on an abstract unix socket,
and ssh can not forward a unix socket that lives in the abstract space.
Using socat can work to serve as a bridge, e.g. when we have this:
$ xprop -root | grep AT_SPI
AT_SPI_BUS(STRING) =
"unix:abstract=/tmp/dbus-Q2svnMqMbO,guid=d35a9f6b8e4cb757b71746025e8e4965"
one can create a socket in the non-abstract space with
$ socat ABSTRACT-CONNECT:'/tmp/dbus-Q2svnMqMbO' UNIX-LISTEN:/tmp/listen,fork
and then run
$ ssh myserver -R '/tmp/foobar:/tmp/listen'
which exposses the at-spi bus on /tmp/foobar on the server. And then use
$ export AT_SPI_BUS_ADDRESS='unix:path=/tmp/foobar'
and then try to run applications. But one gets
(process:8353): dbind-WARNING **: 21:30:14.860: Couldn't register with
accessibility bus: Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security policy blocked the
reply, the reply timeout expired, or the network connection was broken.
(process:8353): dbind-ERROR **: 21:30:14.860: AT-SPI: Couldn't connect to
accessibility bus. Is at-spi-bus-launcher running?
while it's working when ssh-ing to localhost. Looking in the exchanged
data it seems authentication is missing. A cookie-based authentication
could be used instead, but that's not implemented in at-spi.
Samuel