web-dev-qa-db-fra.com

xubuntu: empêche le démon gnome-keyring-daemon d'emprunter l'identité de ssh-agent

Je veux utiliser le vrai agent ssh au lieu de gnome-keyring dans xubuntu. J'ai suivi les étapes de http://dtek.net/blog/how-stop-gnome-keyring-clobbering-opensshs-ssh-agent-ubuntu-1204 , mais gnome keyring s'enregistre toujours comme ssh -agent. Je veux toujours continuer à utiliser gnome-keyring pour d'autres mots de passe

xubuntuxfcegnome-keyringssh-agent
6
JanKanis

Il s'avère que si la compatibilité de gnome est activée dans xfce, xfce4-session démarrera inconditionnellement gnome-keyring-daemon. C'est codé en dur, il n'y a pour le moment aucun moyen de le configurer. La désactivation du mode de compatibilité de gnome entraîne le démarrage du trousseau de clés lors de la connexion et vous devrez fournir votre mot de passe à nouveau si vous le démarrez.

La solution la plus simple semble être d'intercepter l'appel de gnome-keyring-daemon et d'insérer un script qui insère l'indicateur --components dans les arguments afin d'empêcher gnome keyring de remplacer ssh-add.

Exécutez ce qui suit pour déplacer gnome-keyring-daemon:

Sudo mv /usr/bin/gnome-keyring-daemon /usr/bin/gnome-keyring-daemon-wrapped

créer un nouveau démon gnome-keyring avec

Sudo nano /usr/bin/gnome-keyring-daemon

et insérez le contenu suivant:

#!/bin/sh
exec /usr/bin/gnome-keyring-daemon-wrapped --components=pkcs11,secrets,gpg "$@"

Rendre le nouveau gnome-keyring-daemon exécutable avec Sudo chmod +x /usr/bin/gnome-keyring-daemon.

Maintenant, gnome keyring n'essaiera plus de remplacer ssh-add.

Notez que la mise à niveau de votre système rétablira le démon gnome-keyring par défaut. Vous devrez donc probablement exécuter à nouveau les étapes ci-dessus après la mise à niveau.

edit:

Dans xubuntu 14.10, le démarrage fonctionne légèrement différemment dans la mesure où g-k-d est également démarré à partir de la session suivante. Il est possible de remplacer la configuration de départ afin qu'il ne démarre pas le composant ssh, mais même ainsi, g-k-d démarrera son composant ssh lorsque xfce4-session essaiera également de le démarrer. Donc si vous voulez que xfce lance aussi automatiquement les services GNOME, vous aurez toujours besoin du hack ci-dessus. Une autre solution consiste à désactiver les services gnome (Paramètres -> Session et démarrage -> Avancé -> Lancer les services GNOME au démarrage), configurer upstart pour qu'il lance gkd avec l'indicateur --components=pkcs11,secrets,gpg et éventuellement configurer les services de gnome souhaités. pour démarrer manuellement.

(Outre les deux emplacements qui lancent gkd mentionnés ci-dessus, le démon gk est également démarré auparavant par lightdm/PAM afin de recevoir le mot de passe de connexion de l'utilisateur. Mais ce lancement ne configure pas complètement gkd et s'attend à ce qu'il le soit encore. une seconde tentative pour le démarrer, de sorte que cette tentative ne soit pas pertinente pour le problème actuel)

5
JanKanis

C’est un vieux fil de discussion, mais ma solution de contournement pour résoudre ce problème sous Xubuntu 14.04 est simple: il suffit de renaître gnome-keyring-daemon sous Session and Startup. Ce que vous devez faire, c'est simplement exécuter la commande ci-dessous:

$ gnome-keyring-daemon --replace --daemonize --components=pkcs11,secrets,gpg

Nous supprimons "ssh" du composant du trousseau de clés Gnome.

  1. Allez dans Menu> Paramètres> Session et démarrage
  2. Cliquez sur l'onglet Application Autostart
  3. Cliquez sur le bouton Ajouter
  4. La nouvelle fenêtre de l'application apparaîtra, vous pouvez la remplir comme dans l'exemple ci-dessous
    1. Nom: Suppresseur de porte-clés SSH
    2. Description: Supprimer SSH du trousseau GNOME
    3. Commande: gnome-keyring-daemon --replace --daemonize --components=pkcs11,secrets,gpg
  5. Cliquez sur OK

Essayez de vous déconnecter de votre session XFCE et reconnectez-vous. Pour vous assurer que le trousseau de clés Gnome ne gère plus ssh, il suffit de lancer.

$ ssh-add -l
Could not open a connection to your authentication agent.

Si vous avez ce message, cela signifie que le trousseau de clés Gnome ne gère pas votre SSH et que vous êtes libre d'utiliser la mise en œuvre OpenSSH ssh-agent d'origine.

3
rioastamal

Pour donner suite à la réponse de @JanKanis, je l’ai retracée jusqu'à ce que xfce4-session soit à l’origine du lancement de la commande gnome-keyring-daemon --start.

Lorsqu'il est exécuté de cette manière, gnome-keyring-daemon ne vérifie pas si SSH_AUTH_SOCK est déjà défini, ce qui est une "fonctionnalité", car vous pouvez alors avoir à la fois ssh-agent et gnome-keyring-daemon fournissant un socket.

Tout d'abord:

Ajouter ~/.config/upstart/gnome-keyring.conf:

description "GNOME Keyring agents"
author "Dimitri John Ledkov <[email protected]>"

start on (starting xsession-init or starting ssh-agent or starting gpg-agent) and started dbus

task
script
    # Stop because I say so
    stop; exit 0
    eval "$(gnome-keyring-daemon --start)" >/dev/null
    initctl set-env --global SSH_AUTH_SOCK=$SSH_AUTH_SOCK
    initctl set-env --global GPG_AGENT_INFO=$GPG_AGENT_INFO
end script

Maintenant, remplacez gnome-keyring-daemon par un wrapper (j'ai déplacé l'original vers/usr/libexec /):

#!/bin/sh

gkd=/usr/libexec/gnome-keyring-daemon
debug=1
log=${XDG_CACHE_HOME:-"${HOME}/.cache"}/gkd.log

if [ ${debug} -gt 0 ]
then
    echo "================" >> ${log}
    echo "Invoked as $0 $@" >> ${log}
    echo "================" >> ${log}
    /usr/bin/pstree -lag >> ${log}
fi

case "$@" in
    *--start*)
        $gkd --components=pkcs11,secrets,gpg "$@"
        ;;
    *)
        $gkd "$@"
        ;;
esac
if [ ${debug} -gt 0 ]
then
    /usr/bin/pstree -lag  >> ${log}
fi

Le code de débogage est là pour vous aider à comprendre pourquoi il a cessé de fonctionner. Comme aucun de ces programmes n’a de méthode de configuration saine, il n’ya aucun moyen de contourner les commandes de piratage. Dans ce cas, je ne trouve aucune méthode de configuration documentée pour xfce4-session afin de ne pas envier gnome-keyring-daemon --start, qui n'a pas d'autres effets secondaires. Ils font tous des hypothèses sur les choses en cours d'installation et vont donc de l'avant dans l'esprit de l'utilisateur.

3
Melvyn Sopacua

Voici une version moins invasive du script publié par JanKanis. Il accepte tous les composants qui lui ont été transmis, mais retire le composant SSH.

#!/bin/bash

ARGS="$@"

COMPONENTS=""
if [[ $ARGS =~ \-\-components= ]]; then
    component_match_expression='(\-\-components=([0-9a-z,]+))'
    COMPONENTS=$(echo $ARGS | grep -oP "$component_match_expression")

    ARGS=$(echo $ARGS | sed -E "s/$component_match_expression//")

    COMPONENTS="--components=$(echo $COMPONENTS | grep -oP '(?<=\-\-components=)([0-9a-z,]+)' | sed -e 's/ssh//' -e 's/,,/,/')"
    if [ "$COMPONENTS" != "--components=" ]; then
        ARGS="$ARGS $COMPONENTS"
    else
        exit 0
    fi
fi

/usr/bin/gnome-keyring-daemon-wrapped $ARGS
2
SPoage

Je viens de rencontrer ce problème sur Xubuntu 16.04 et je voulais aussi travailler à la fois ssh-agent et gpg-agent.

Tout d'abord, je me fichais de gnome-keyring, j'ai donc supprimé tous les paquets associés. par exemple.

Sudo dpkg -P libgnome-keyring-common libgnome-keyring0 libp11-kit-gnome-keyring libpam-gnome-keyring libgnomeui-0 python-gnome2 gir1.2-gnomekeyring-1.0 system-config-printer-gnome

À ce stade, ssh-agent et gpg-agent fonctionnaient tous les deux avec succès, mais gpg n'a pas pu se connecter à gpg-agent, car $GPG_AGENT_INFO n'a pas été défini. C'est vraiment bizarre parce que si nous regardons dans /etc/X11/Xsession.d/90gpg-agent, cela commence clairement à se définir. Quelque chose doit être en train de le défaire.

Pour aider à trouver le coupable, j'ai créé un fichier de session personnalisé:

$ cat /usr/share/xsessions/xsession.desktop 
[Desktop Entry]
Version=1.0
Name=Xsession
Exec=/etc/X11/Xsession
Icon=
Type=Application

J'ai ensuite créé un fichier personnalisé ${HOME}/.xsession et je l'ai rendu exécutable, avec les éléments suivants:

#!/bin/sh

# DEBUG
echo "GPG_AGENT_INFO: ${GPG_AGENT_INFO}" > "${HOME}/GPG_AGENT_INFO"

# Defined by /etc/alternatives/x-session-manager
exec x-session-manager

Je me suis déconnecté, j'ai redémarré lightdm et me suis reconnecté (avec la session "Xsession" sélectionnée), puis j'ai inspecté ${HOME}/GPG_AGENT_INFO. Effectivement, la variable d'environnement était toujours définie. C'était donc quelque chose de stupide que Xfce4 faisait.

En fouillant, je suis finalement tombé sur ceci:

$ strings /usr/bin/xfce4-session | grep gpg
/startup/gpg-agent/enabled
gpg-agent
gpg-agent-info
GNOME compatibility is enabled and gnome-keyring-daemon is found on the system. Skipping gpg/ssh-agent startup.
gpg-agent is configured as SSH agent, but gpg-agent is disabled or not found
Failed to kill gpg-agent with pid %d
$

Il semble que xfce4-session annule probablement la définition de la variable lorsqu'elle tente de lancer gnome-keyring-daemon. La solution nécessite donc deux étapes. Tout d’abord, allez à Applications -> Settings -> Session and Startup -> Advanced et cochez Launch GNOME services on startup. Créez ensuite un fichier exécutable nommé gnome-keyring-daemon quelque part dans votre $PATH avec le contenu suivant:

#!/bin/sh
#
# This script exists to satisfy an XFCE4 check which prevents
# the GPG_AGENT_INFO environment variable getting unset.

Déconnectez-vous et dans une fois de plus, et vous devriez être trié. Vous devriez aussi pouvoir maintenant supprimer /usr/share/xsessions/xsession.desktop et ${HOME}/.xsession si vous les avez également créés, car ils étaient simplement destinés au débogage.

2
boltronics