utilisation de gnome-keyring-daemon sans X


25

Je me demande s'il est possible d'utiliser gnome-keyring-daemon sans X. Normalement, il présentera une invite graphique afin d'acquérir un mot de passe pour le trousseau de clés; Y a-t-il un moyen de contourner ceci? Je voudrais pouvoir utiliser ubuntu one sans avoir à démarrer une session graphique et à taper mon mot de passe.

Réponses:


11

Vous pouvez utiliser pam_gnome_keyring.sopour démarrer et déverrouiller le démon. GDM le fait déjà; car login, vous devez le configurer manuellement.

Ajoutez ces lignes à /etc/pam.d/login:

auth facultatif pam_gnome_keyring.so
session facultative pam_gnome_keyring.so auto_start

Si vous vous connectez sans mot de passe (SSH avec Kerberos ou clés publiques), cela peut fonctionner: (je ne l'ai pas testé)

echo -n "mypassword" | gnome-keyring-daemon --login

(Vous avez toujours besoin que le démon soit en cours d'exécution - démarré via PAM ou avec --daemonize.)


Le deuxième cas est le cas dans mon cas. Cette --loginoption (non documentée?) Est assez utile, bien que je ne veuille certainement pas conserver mon mot de passe non haché dans un script ou le mettre sur une ligne de commande. lire en mode sans écho à partir d'un script (non-shell-language) qui transmet ensuite cette entrée au démon généré serait probablement un bon moyen de le faire. Je ne devrais avoir à démarrer ce processus qu'une fois par démarrage, il est donc logique de taper le mot de passe; J'ai juste besoin de pouvoir le faire sur la ligne de commande plutôt que via la boîte de dialogue GTK.
intuition

1
euh ... peu importe, c'est documenté par gnome-keyring-daemon --help. Je viens de vérifier la page de manuel et / usr / share / doc.
intuition

2
@intuited: Eh bien, alors faites quelque chose comme ça: read -rsp "Password: " pass; echo -n "$pass" | gnome-keyring-daemon --logindans un script.
grawity

En fait, oui, cela fonctionnerait; J'oubliais que l'écho était intégré.
intuition

En réponse à l'ancien commentaire de @intuited: gnome-keyring-daemon --helpme donne un bon aperçu, mais man gnome-keyring-daemoncontient juste une brève description du programme lui-même mais sans argument.
feeela

10

Synopsis

L'installation de svn avec prise en charge des trousseaux et l'installation de l'application Collabnet keyring_tool sont déjà effectuées pour nos serveurs Linux.

1) Configurez le client SVN pour utiliser le trousseau de clés:

1.1) Modifier ~ / .subversion / config

[auth]
password-stores = gnome-keyring

1.2) Modifier ~ / .subversion / serveurs

[global]
store-passwords = yes
store-plaintext-passwords = no

2) Créez un trousseau de clés pour votre mot de passe. Vous serez invité à créer un nouveau mot de passe pour déverrouiller le trousseau de clés; cela peut être tout ce que vous souhaitez:

keyring_tool --create=svn

3) Définissez le nouveau trousseau de clés par défaut:

keyring_tool --setdef=svn

4) Dans .bash_profile ou .bash_login (en supposant que vous utilisez bash comme terminal)

    if [ -e /usr/bin/gnome-keyring-daemon ]; then
      if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
        # Create dbus transport link for SVN to talk to the keyring.
        eval `dbus-launch --sh-syntax`

        # Start the keyring daemon.
        # The use of export here captures the GNOME_KEYRING_PID, GNOME_KEYRING_SOCK
        # env values echoed out at startup.
        export `/usr/bin/gnome-keyring-daemon`
      fi
    fi

5) Dans .bash_logout

    # Kill the message bus established for SVN / Keyring communication
    if [ ! -z "`kill -0 $DBUS_SESSION_BUS_PID 2>&1`" ]; then
      kill $DBUS_SESSION_BUS_PID > /dev/null 2>&1
    fi

    # Kill the Gnome Keyring Daemon prior to logout.
    if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
      kill $GNOME_KEYRING_PID > /dev/null 2>&1
    fi

Contexte

J'ai rencontré un problème similaire en essayant d'établir un moyen sans tracas pour garantir l'accès utilisateur autorisé à certains dépôts SVN au travail. Fondamentalement, nous avons dû forcer la vérification des informations d'identification à chaque fois qu'un utilisateur accède au serveur, donc même la commande svn update nécessiterait une authentification. Il est clair que le stockage des mots de passe en texte clair était sorti.Ainsi, avec un peu de recherche, j'ai utilisé le gnome-keyring comme un moyen de harceler notre base d'utilisateurs avec des demandes d'authentification constantes tout en gardant les utilisateurs non autorisés hors des référentiels, ils ne devraient pas avoir accès à la vue.

Une grande partie de notre travail quotidien se fait via des tunnels ssh dans un serveur RedHat sans support X, j'ai donc dû trouver un moyen de contourner le support X11. Après quelques recherches, j'ai réussi à trouver le chemin ici:

Matériel d'origine

http://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh -session

La clé ici utilise le Collabnet keyring_tool pour créer un trousseau de clés sans le client gnome-keyring-manager et établir le lancement de dbus vous-même plutôt que de laisser SVN gérer la configuration. SVN utilise DBUS pour se connecter au démon gnome-keyring-daemon et affecter l'authentification globale. En démarrant et en supprimant manuellement la session dbus avec la syntaxe -sh, vous évitez d'essayer de vous connecter à un client X au démarrage de dbus. Si vous démarrez simplement le démon gnome-keyring-daemon et essayez d'utiliser SVN, il vous demandera toujours votre mot de passe de trousseau mais vous demandera également vos informations d'identification SVN. Le dbus échouera lorsque SVN essaiera de le démarrer en raison de l'absence d'un client X; apparemment, SVN n'utilise aucun indicateur spécial lors du démarrage du dbus.


Merci beaucoup pour cela, j'ai tiré mes cheveux en essayant de me débarrasser d'une erreur "CRITICAL **: Erreur de communication avec gnome-keyring-daemon" sur git pull. Vos modifications apportées à ~ / .profile et ~ / .bash_logout ont corrigé cela ... Toujours pas enregistrer les mots de passe mais je suis un pas de plus! (Ubuntu 16.04.1 LTS)
Chris B

1

Tout d'abord, ce que vous voulez vraiment faire, c'est exécuter Ubuntu One strictement à partir de la ligne de commande. Jetez un œil à la FAQ Ubuntu One . La FAQ dit que ce n'est pas possible actuellement, mais il existe des outils CLI comme u1sdtool et u1sync . Il y a aussi un ensemble de FAQ sur Ubuntu One sur Launchpad; le contenu peut être le même que le lien wiki.ubuntu.com précédent.

En ce qui concerne votre question réelle sur gnome-keyring-daemon , la FAQ suggère (1) de définir la connexion automatique et (2) de synchroniser votre mot de passe de trousseau avec votre mot de passe de connexion. Ce serait (en théorie) éviter le mot de passe rapide, mais il aurait besoin d' au moins une base de session X en cours d' exécution.

Il y a un bug / liste de souhaits Ubuntu One sur Launchpad qui demande de faciliter la gestion des systèmes sans tête. Apparemment, la construction à partir des sources est recommandée pour une installation légère (pour éviter d'avoir besoin de toutes les bibliothèques GUI et autres). Ce commentaire est ancien, mais particulièrement intéressant:

Le problème est que nous utilisons python-gnomekeyring. Pour que nous puissions prendre en charge sans tête, nous devrons passer au porte-clés python et gérer le stockage des jetons ailleurs que gnome-keyring sur les écrans sans tête. Cependant, rien de tout cela ne se produira pour l'emballage Karmic car il est gelé, et ce changement ne serait pas acceptable dans une SRU.

Pour Lucid, nous devrions avoir un service d'authentification plus robuste, ce qui devrait nous permettre de mieux prendre en charge les affichages sans tête.

Je ne peux pas dire si ce "service d'authentification plus robuste" a été réellement mis en place pour Lucid; sur la base des dépendances du package, il semble que le client Ubuntu One dépend toujours de python-gnomekeyring.


0

J'ai réussi à faire fonctionner mysql-workbench avec gnome-keyring dans une session SSH x-forwardée. Il s'agissait d'un compte qui utilisait l'authentification publickey (pas de mot de passe).

J'ai utilisé dbus-run-session pour y parvenir une fois connecté à la session ssh:

dbus-run-session bash -c 'GNOME_KEYRING_CONTROL=1 mysql-workbench --verbose'

si tout va bien cette information est utile à quelqu'un!


Cela a permis de faire un pas de plus vers l'exécution de mysql-workbench dans un conteneur Docker et l'exportation de l'affichage vers mon hôte Mac. Lorsque j'essaye d'ajouter un mot de passe à une nouvelle connexion, il me montre l'invite, mais après avoir tapé le pwd, j'obtiens: "Impossible d'exécuter le programme org.freedesktop.secrets: opération non autorisée". Des indices?
Ricardo Pesciotta
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.