Mi caso de uso es que tengo un servidor sin cabeza en el que se realiza el desarrollo de software. Usualmente habilito el reenvío X11 para las conexiones SSH, pero no puedo para ubicaciones distantes con conexiones lentas.
Necesito almacenamiento seguro y almacenamiento en caché para mis credenciales de git ya que trabajo regularmente con 18-20 repositorios en un árbol, por lo que estoy usando git-credential-gnome-keyring como git credential.helper, que se comunica usando el libgnome-keyring al gnomo-llavero-demonio. Para probar soluciones, configuré una PC con un monitor, confirmó que el llavero funcionaba de manera predeterminada en el sistema y luego lo probé con SSH. Funciona con reenvío X11, pero no funciona sin él.
Cuando estoy conectado sin reenvío X11, aparece el siguiente error cuando se consulta el llavero y la herramienta vuelve a aparecer en la línea de comandos:
** (process:18305): CRITICAL **: Error communicating with gnome-keyring-daemon
La investigación revela que el problema base es que gnome-keyring-daemon espera que las conexiones usen dbus para hablar con él. El dbus no se inicia si no hay una sesión X11, por lo que no hay un bus dbus común para el gnome-keyring-daemon y el libgnome-keyring para conectarse.
He encontrado dos soluciones que otros han publicado para este problema, aunque ninguna funciona correctamente para mí.
- Obtenga un puerto DBUS de una sesión existente que use X11
- Inicie manualmente un nuevo puerto DBUS
Cuando se conecta a un puerto DBUS existente, el concepto base es encontrar el PID de una sesión de inicio de sesión existente, volcar el entorno para ese PID desde el procfs, buscarlo DBUS_SESSION_BUS_ADDRESSy exportarlo en el entorno actual. Dado que esta es la variable utilizada para publicar el bus DBUS que está siendo utilizado por todo en las sesiones, establecer esto debería permitir que todo en la sesión se comunique en un bus DBUS común, aunque es el bus asociado con una sesión diferente.
Fuentes aquí:
https://ubuntuforums.org/showthread.php?t=1059023
https://ask.fedoraproject.org/en/question/45246/error-communicating-with-gnome-keyring-daemon-in-ssh- sesión /
Código agregado a mi .bashrc que se ejecuta al iniciar sesión ssh:
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
local myPID=`pgrep "(.*session|fluxbox)" | head -n1`
if [ -n "$myPID" ] ; then
local myVar=`cat /proc/${myPID}/environ | grep -z "^DBUS_SESSION_BUS_ADDRESS=" | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'`
if [ -n "$myVar" ] ; then
export DBUS_SESSION_BUS_ADDRESS=$myVar
fi
fi
fi
El segundo método, el lanzamiento manual de DBUS para la sesión, consiste en utilizar dbus-launchpara crear una nueva sesión y configurar el DBUS_SESSION_BUS_ADDRESSentorno, luego iniciar gnome-keyring-daemon con todos los servicios necesarios para que vea la dirección del bus DBUS que hemos creado. en lugar de una dirección de autobús vacía. Esta solución puede o no requerir que se cambie gnome-keyring-daemon para ejecutar una instancia por sesión en lugar de una instancia por sistema, pero no está claro.
Fuentes:
Comenzando con el número 8: https://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome- keyring-in-an-ssh-session
Cómo modificar la línea "Exec" de un servicio dbus sin perder los cambios en caso de actualización
Código agregado a mi .bashrc que se ejecuta al iniciar sesión ssh:
# then DBUS wasn't started for this session and needs to be
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
# start a new dbus session and make sure the variables are exported (automatic output)
eval `dbus-launch --sh-syntax`
# make sure gnome-keyring-daemon is using all the necessary components (it may not be by default)
# Capture the output, which is a series of variable setting commands, one on eachline, and
# export them while setting them
while read -r LINE
do
export $LINE
done <<< $(gnome-keyring-daemon --start --components=gpg,pkcs11,secrets,ssh)
fi
Ambas soluciones dan el mismo resultado fallido. En lugar de producir inmediatamente el error que indica que el demonio gnome-keyring no se puede comunicar, el proceso se bloquea por un tiempo y luego produce esta salida:
Gkr-Message: secret service operation failed: 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:31155): CRITICAL **: Error communicating with gnome-keyring-daemon
No tengo claro cómo el gnome-keyring-daemon está interactuando con DBUS, pero a partir del segundo conjunto de errores resulta claro que no es accesible a través de un bus DBUS recién creado, o un proceso cruzado en un bus DBUS diferente. Algo de lo que he encontrado sugiere que el gnome-keyring-daemon podría necesitar el DBUS iniciado antes, pero no está claro si ese es el caso del uso (libgnome-keyring) o el daemon.
¿Cómo hago para que esto funcione?
fuente
Respuestas:
Esta puede ser una respuesta estúpida ... pero, gnome-keyring necesita acceso a una sesión X11, al menos para solicitar la clave maestra. Entonces, es simplemente imposible que funcione, por diseño ... ¿no?
EDITAR: Tal vez no es tan imposible. Vea esta publicación , se parece a su problema:
fuente