Où gnome-keyring place-t-il $ SSH_AUTH_SOCK?


10

Je suis en train de me débarrasser d' gnome-keyringun agent SSH.

Les choses que j'ai faites

  • Recherche sur Internet pendant des heures.
  • Changé des trucs et redémarré, souvent.
  • Enfin, juste rm-ed toutes les choses de démarrage automatique liées à SSH.

Cette dernière chose a fonctionné comme par magie car il n'y a plus de socket pour l'agent là-bas:

/run/user/[uid]/keyring/ssh

Problème

Le problème reste que malgré mon obtention du merveilleux résultat mentionné ci - dessus, quelque chose dans gnome-keyringinsiste encore sur la mise SSH_AUTH_SOCKà la désormais non existante prise ci - dessus. C'est comme des zombies, ces choses ne meurent jamais.

Question

Qu'est-ce qui définit cette variable et où est-elle effectuée?

Pièges

  • Je ne demande pas comment je peux réinitialiser cette variable à une autre valeur.
  • Je ne demande pas comment définir cette valeur à l'échelle du système ou dans un fichier de configuration shell.
  • Je ne demande pas quelques incantations vaudou init-script pour geler, définir, réinitialiser, désinstaller ou remplacer quoi que ce soit.
  • Je ne demande pas de conseils sur la façon de désinstaller la chose: j'en ai toujours besoin pour mes mots de passe et il semble être le gestionnaire de mots de passe le plus intégré et le plus raffiné de Gnome.

Je veux que ce truc soit désactivé comme il se doit.


2
Désinstaller gnome-keyring?
rudimeier

1
@rudimeier: J'ai toujours besoin de gnome-keyring pour mes mots de passe et pour autant que je sache, il n'y a rien de plus raffiné et intégré dans Gnome.
JohnW

@rudimeier même cela ne semble pas aider. Je l'ai essayé.
André Borie

Réponses:


8

Laissez-moi deviner - vous utilisez Wayland. J'ai rencontré ce problème aujourd'hui et j'ai pensé partager la solution.

Gnome-Session a un remplacement codé en dur pour SSH_AUTH_SOCKunderwayland pour une raison quelconque. Voir le commit suivant: https://github.com/GNOME/gnome-session/commit/a8896ccad65583885735a04205351f48a42f29ae

La solution? Définir une variable d'environnement pour désactiver ce comportement: GSM_SKIP_SSH_AGENT_WORKAROUND=1. Cela court-circuite le code de réglage de l'environnement.

Pour les personnes qui trouvent cela qui essaient également de configurer ssh-agent: Dans mon fichier d'unité systemd pour ssh-agent, j'ai la ligne suivante:

ExecStartPost=/usr/bin/bash -c "/usr/bin/systemctl --user set-environment SSH_AUTH_SOCK=$SSH_AUTH_SOCK GSM_SKIP_SSH_AGENT_WORKAROUND=1"

Le fichier complet ressemble à ceci:

[Unit]
Description=SSH Agent
IgnoreOnIsolate=true

[Service]
Type=forking
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -a $SSH_AUTH_SOCK
ExecStartPost=/usr/bin/bash -c "/usr/bin/systemctl --user set-environment SSH_AUTH_SOCK=$SSH_AUTH_SOCK GSM_SKIP_SSH_AGENT_WORKAROUND=1"

[Install]
WantedBy=default.target

Merci! Sur Ubuntu v17.10 Artful Aardvark, ajouter simplement export GSM_SKIP_SSH_AGENT_WORKAROUND=1à mon ~ / .profile et redémarrer a corrigé ma configuration qui fonctionnait auparavant sur v17.04.
Stephen Niedzielski

Cela semble affecter plus que Wayland, j'ai rencontré cela en essayant d'utiliser gnome-flashback + i3.
dragon788

Veuillez noter que ce hack fonctionne jusqu'à Gnome 3.24 ou plus ancien ( wiki.archlinux.org/index.php/GNOME/… )
Pablo Olmos de Aguilera C.

5

(L'environnement OP n'est pas connu, donc les chemins donnés ici sont ceux trouvés sur ma machine Ubuntu)

Où gnome-keyring place-t-il SSH_AUTH_SOCK?

Pour répondre à la question principale dans le titre, SSH_AUTH_SOCK est défini par gnome-keyring in /usr/share/upstart/sessions/gnome-keyring-ssh.confavec la commande suivante:

initctl set-env --global SSH_AUTH_SOCK=$SSH_AUTH_SOCK

Citant le initctlmanuel:

initctl set-env VARIABLE[=VALUE]

Ajoute ou met à jour une variable dans une table d'environnement de travail. Les variables définies de cette manière s'appliqueront à tous les processus de démarrage ultérieurs d'un travail.

-g, --global

Fonctionne sur la table d'environnement de travail globale et toutes les tables d'environnement de travail en cours d'exécution.

D'où vient SSH_AUTH_SOCK en premier lieu?

La initctlcommande ci-dessus est conditionnée au fait que la variable d'environnement SSH_AUTH_SOCK existe déjà. Alors, est-ce une situation de poulet et d'oeuf? Qu'est-ce qui le définit?

SSH_AUTH_SOCK est initialement défini par l'agent ssh d'origine qui est démarré au tout début de la session X. Citant le manuel:

Un socket de domaine UNIX est créé et le nom de ce socket est stocké dans la SSH_AUTH_SOCKvariable d'environnement. Le socket est rendu accessible uniquement à l'utilisateur actuel.

MAIS, ce que fait le composant ssh du gnome-keyring est de se substituer à l'agent ssh existant. Par conséquent, il écrase SSH_AUTH_SOCK avec son propre socket /run/user/.../keyring-.../sshafin que les applications lui parlent, et non à ssh-agent.

Comment le désactiver

Maintenant, répondons à la dernière phrase "Je veux que cette chose soit désactivée". Ce que l'OP veut, c'est désactiver l'écrasement de SSH_AUTH_SOCK par le composant ssh dans gnome-keyring. Ils veulent récupérer la "vraie" variable SSH_AUTH_SOCK initialement définie par ssh-agent.

Le composant ssh est démarré par le même script de démarrage mentionné ci-dessus ( /usr/share/upstart/sessions/gnome-keyring-ssh.conf) mais à une condition: la chaîne X-GNOME-Autostart-enabled=falsene doit être trouvée dans aucun de ces fichiers:

  • (conf à l'échelle du système) /etc/xdg/autostart/gnome-keyring-ssh.desktop
  • (conf de l'utilisateur) ~/.config/autostart/gnome-keyring-ssh.desktop

Par conséquent, si vous souhaitez le désactiver, il vous suffit d'ajouter une ligne X-GNOME-Autostart-enabled=falseà l'un de ces fichiers, de préférence celui de votre répertoire HOME.


J'ai essayé de désactiver les entrées de démarrage automatique pour le trousseau de clés Gnome et il semble que la variable soit toujours là, mais pointe vers un socket inexistant (donc la désactivation du trousseau a fonctionné, mais la variable est définie ailleurs). J'utilise une machine Archlinux donc il n'y a pas de parvenu et il n'y a rien d'évident dans systemd qui puisse régler la variable ..
André Borie

@ AndréBorie Je ne connais ni Arch ni systemd. Quelle est la nouvelle valeur du chemin du socket? Sur mon macihne, ssh-agent le définit généralement sur /tmp/ssh-XXX/agent.PID. Ssh-agent est-il toujours dans votre liste de processus?
xhienne

Le chemin est comme dans la question d'origine. Aucun agent SSH ni trousseau de clés n'est en cours d'exécution.
André Borie

Cette réponse est vraiment ancienne mais j'espère que vous pourrez m'aider aussi unix.stackexchange.com/questions/422574/…
Ojs

3

https://wiki.archlinux.org/index.php/GNOME/Keyring#Disable_keyring_daemon_components

Si vous souhaitez exécuter un autre agent SSH (par exemple, ssh-agent ou gpg-agent, vous devez désactiver le composant ssh du porte-clés GNOME. Pour ce faire, de manière locale au compte:

mkdir ~/.config/autostart
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/ &&
echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-ssh.desktop

Déconnectez-vous ensuite.

Légèrement édité, supprimant l'utilisation apparemment inutile de printf


Cela fonctionne également pour moi sur Ubuntu 14.04.
pts

Cela est vrai pour 3.24 et plus récent.
Pablo Olmos de Aguilera C.

0

Depuis Gnome 3.18, le socket semble être stocké dans ~/.cache/keyring-(some random string)/ssh

À une supposition, il est défini par gnome-keyring-daemon.

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.