utilisation de gnome-keyring sans session x


13

Mon cas d'utilisation est que j'ai un serveur sans tête sur lequel le développement logiciel est effectué. J'active généralement le transfert X11 pour les connexions SSH, mais je ne peux pas pour les emplacements distants avec des connexions lentes.
J'ai besoin d'un stockage et d'une mise en cache sécurisés pour mes informations d'identification git car je travaille régulièrement avec 18-20 référentiels dans une arborescence, donc j'utilise git-credential-gnome-keyring comme git credential.helper, qui communique à l'aide de libgnome-keyring au démon gnome-keyring-daemon. Pour tester les solutions, j'ai configuré un PC avec un moniteur, confirmé le trousseau de clés fonctionnait par défaut sur le système, puis l'ai essayé avec SSH. Il fonctionne avec le transfert X11, mais ne fonctionne pas sans lui.

Lorsque je suis connecté sans transfert X11, l'erreur suivante se produit lorsque le trousseau de clés est interrogé et l'outil revient à l'invite sur la ligne de commande:

** (process:18305): CRITICAL **: Error communicating with gnome-keyring-daemon

L'enquête révèle que le problème de base est que gnome-keyring-daemon attend que les connexions utilisent dbus pour lui parler. Le dbus n'est pas démarré s'il n'y a pas de session X11, il n'y a donc pas de bus dbus commun auquel le gnome-keyring-daemon et libgnome-keyring peuvent se connecter.

J'ai trouvé deux solutions que d'autres ont publiées sur ce problème, mais aucune ne fonctionne correctement pour moi.

  1. Obtenir un port DBUS à partir d'une session existante qui utilise X11
  2. Lancer manuellement un nouveau port DBUS

Lors de la connexion à un port DBUS existant, le concept de base consiste à trouver le PID d'une session de connexion existante, à vider l'environnement de ce PID à partir du procfs, à le rechercher DBUS_SESSION_BUS_ADDRESSet à l'exporter dans l'environnement actuel. Comme il s'agit de la variable utilisée pour publier le bus DBUS utilisé par tout dans les sessions, sa définition devrait permettre à tout ce qui se trouve dans la session de communiquer sur un bus DBUS commun, bien qu'il s'agisse du bus associé à une session différente.
Sources ici:
https://ubuntuforums.org/showthread.php?t=1059023

https://ask.fedoraproject.org/en/question/45246/error-communicating-with-gnome-keyring-daemon-in-ssh- session /

Code ajouté à mon .bashrc en cours d'exécution lors de la connexion 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

La deuxième méthode, le lancement manuel de DBUS pour la session, consiste à utiliser dbus-launchpour créer une nouvelle session et définir l' DBUS_SESSION_BUS_ADDRESSenvironnement pour l'environnement, puis à démarrer le démon gnome-keyring-daemon avec tous les services nécessaires pour qu'il puisse voir l'adresse du bus DBUS que nous avons créée. plutôt qu'une adresse de bus vide. Cette solution peut nécessiter ou non que gnome-keyring-daemon soit modifié pour exécuter une instance par session plutôt qu'une instance par système, mais ce n'est pas clair.
Sources:
À partir du numéro 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

Comment modifier la ligne "Exec" d'un service dbus sans perdre les changements en cas de mise à niveau
Code ajouté à mon .bashrc en cours d'exécution lors de la connexion 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

Les deux solutions donnent le même résultat défaillant. Au lieu de produire immédiatement l'erreur indiquant que le démon gnome-keyring-daemon ne peut pas être communiqué, le processus se bloque pendant un certain temps, puis produit cette sortie:

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

Je ne sais pas comment le gnome-keyring-daemon interagit avec DBUS, mais il ressort clairement du deuxième ensemble d'erreurs qu'il n'est pas accessible via un bus DBUS nouvellement créé, ou un processus croisé sur un bus DBUS différent. Certains de ce que j'ai trouvé suggèrent que le démon gnome-keyring-daemon pourrait avoir besoin que le DBUS soit démarré avant, mais il n'est pas clair si c'est le cas pour l'utilisation (libgnome-keyring) ou le démon.

Comment puis-je faire fonctionner cela?


en effet, la session dbus doit être lancée avant le trousseau de clés utilisateur (démon), même lorsque vous utilisez le transfert x11, vous utilisez le trousseau de clés local et non pas le distant ...
intika

Comme la première approche l'a montré, j'ai démarré la session dbus avant le démarrage du démon de trousseau de clés. Et vous dites que lorsque j'exécute une commande qui utilise le démon gnome-key-ring sur mon système distant, il établit une connexion via le socket $ DISPLAY vers mon système source pour se connecter à la session dbus là-bas? Cela semble extrêmement improbable, mais je n'en sais pas assez pour être totalement en désaccord. Dbus n'est pas un outil graphique, c'est un outil de communication inter-processus qui est souvent utilisé par les applications graphiques.
mtalexan

Il suffit de spitballer ici, mais avez-vous essayé d'utiliser xvfb pour "truquer" une xsession. Cela pourrait fonctionner si vous l'avez exécuté (et terminé l'initialisation) et exporté le var DISPLAY de telle sorte que dbus sait qu'un Xserver est en cours d'exécution
TAAPSogeking

Réponses:


0

Cela peut être une réponse stupide ... mais, gnome-keyring a besoin d' accéder à une session X11, au moins pour vous demander la clé principale. Donc, il est tout simplement impossible de le faire fonctionner, par conception ... n'est-ce pas?

EDIT: Peut-être pas si impossible. Voir cet article , ressemble à votre problème:

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.