On 03/29/2013 12:16 PM, m.roth at 5-cent.us wrote: > I've finally got it working. First, I create that file > /etc/X11/xinit/Xclients.d/Xclients.gnome-session.sh, whose contents are > #!/bin/sh > exec -l $SHELL -c "$SSH_AGENT gnome-session" I just realized that Xclients.gnome-session.sh is called as: exec -l $SHELL -c "$CK_XINIT_SESSION $SSH_AGENT $XCLIENTS_D/Xclients.$1.sh" ... which means that Xclients.gnome-session.sh is executed in an empty environment, which is why you're not getting two ssh-agents. It also means that it'll execute the same commands as: #!/bin/sh exec gnome-session > Now, I do *not* have a clue of the impact of not letting > gnome-keyring-agent run. If someone here does, feel free to discuss it, > and let me know if I *can* just chmod -x. You *can*, but the users will lose GPG, PKCS11, and "secrets" support. IIRC, that means they can't do any local admin stuff, because GNOME can't prompt them for passwords any longer. It'll also be reset whenever you update GNOME packages. You're better off removing read access to /etc/xdg/autostart/gnome-keyring-ssh.desktop, but that will also be reset whenever you update. (I've tested this) If the user turns off SSH support in gnome-session-properties, the change will not be impacted by upgrades, so that's the most reliable thing. (I've tested this, too) > Anyway, my hack which works neatly is to create a three line shell script > that goes into the users .<shellrc> file, whose contents are: Normally you'd want to put environment variables like that into .bash_profile instead, so that it's not called by non-login shells.