Programa ejecutado en SSH accediendo a pulseaudio en la máquina donde se ejecuta

Me gustaría ejecutar un programa de forma remota (a través de ssh) pero con audio yendo a la máquina remota donde realmente se ejecuta el programa. Esto normalmente funcionaría con ALSA, pero pulseaudio aparentemente verifica algunos autenticadores de sesión antes de permitir la conexión de un cliente.

¿Cómo hacer que esta verificación sea menos estricta?

local: $ ssh remote           # remote is running pulseaudio and has sound hardware

remote:$ paplay something.wav
Connection failure: Connection refused

pa_context_connect() failed: Connection refused
remote:$ audacious something.mp3 # opens on local's X11 display
pulseaudio: Failed to connect to server: Connection refused
pulseaudio: Failed to connect to server: Connection refused

En mi caso, lo siguiente funcionó para mí:

pax11publish -r

El culpable es que ssh no establece DBUS_SESSION_BUS_ADDRESScuál se usa para conectarse a Pulseaudio. Una solución (basada en esta publicación ) fue agregar las siguientes líneas a my ~/.bashrc, que se usan al conectarse a través de ssh:

if [[ -n $SSH_CLIENT ]]; then
    export DBUS_SESSION_BUS_ADDRESS=`cat /proc/$(pidof nautilus)/environ | tr '\0' '\n' | grep DBUS_SESSION_BUS_ADDRESS | cut -d '=' -f2-`
fi

utiliza el PID de nautilus (puede que tenga que cambiar eso para obtener algún proceso que siempre se ejecuta en la sesión) y busca sus variables de entorno DBUS_SESSION_BUS_ADDRESSy lo exporta.

Esto hace que los programas que se conectan a Pulse funcionen bien. Otros programas que se comunican a través de la sesión d-bus también funcionan (como audtool para conducir audazmente por la línea de comandos).