On 03/29/2013 08:19 AM, m.roth@5-cent.us wrote:
Well, no. If you look at the stock /etc/X11/xinit/xinitrc-common. at the bottom of the file, that's where it sets this stuff. As I said, we *have* to use the compiled from more recent versions of ssh, because the current stock version doesn't support US gov't PIV cards for authentication. And doing this, I only get one agent, and it gets killed automagically when I log out, as expected.
I understand that. I'm just trying to point out that if you set the SSH_AGENT variable, it should be much less complex than it sounds in your description. ssh-agent runs the shell as a child, and exits when the session does. There's no "killing" involved.
a) /usr/share? Why are system-wide configuration files NOT IN /etc? b) UTF-8? What freakin' morons decided it shouldn't be plain ascii, like everything else? #$%^&*$%^&*($%^&*($%^&*(%^&*()_+
"Everything else" is UTF-8 on any sane Unix-like system that supports non-English languages.
Pause for some googling, ah, here's my answer that's less ugly, from https://ask.fedoraproject.org/question/10225/is-it-possible-to-replace-gnome-keyring-daemon-with-ssh-agent/, which is to create /etc/X11/xinit/Xclients.d/Xclients.gnome-session.sh, whose contents are #!/bin/sh exec -l $SHELL -c "$SSH_AGENT gnome-session"
...yeah, that does look like a better option. I was actually going to suggest the same after looking at Xsession again.
The only thing I'd point out is that Xclients.gnome-session.sh will be run as a child of SSH_AGENT , so now you have two SSH_AGENT processes running. The script really only needs to exec gnome-session:
#!/bin/sh exec gnome-session
On the other hand, if your script launches your local copy of ssh-agent, while it would still be a child of the system's ssh-agent, you'd only ever have to maintain the one file:
#!/bin/sh exec /usr/local/bin/ssh-agent gnome-session
...and you wouldn't have to modify xinitrc-common at all.
Xclients, which runs your session. You shouldn't need to change anything at all, unless your newer ssh-agent is at a different path. So, in that case, the only thing you should need to change is to run gnome-session-properties, and uncheck "SSH Key Agent".
First, of course it's in a different path.
I don't think it's wrong to replace Red Hat's ssh with your own package, so I don't think there's any "of course" about it. I understand that you don't like GNOME, but please direct your frustration at something other than the people trying to help you.
Second, no, I do *not* want to run a gnome thing - I need to a) do this from a command line, and b) fix it so it can be built that way, or updated. This isn't my machine, I've got dozens of users, and need to administer this remotely, without having to make them stop what they're doing so I can screw with this.
Well, you could remove /etc/xdg/autostart/gnome-keyring-ssh.desktop, or make it unreadable. I don't think the user's session would have a copy of that.
Ok, I followed the guy's instructions, but a) I'm afraid to let the keyring not run,
It'd probably break NetworkManager, at least.
and b) I get the one agent running... but gnome-keyring-agent runs *after* it, and so overwrites the environment variables, which means this is the final trick I need to resolve. As a first question on that, in that created file, /etc/X11/xinit/Xclients.d/Xclients.gnome-session.sh, I've got the one line; however, in /etc/gdn/Xession (really /etc/X11/Xsession), to start gnome, it has, as you can see above, *two* execs.
That's probably a mistake, but it might be set that way in case "SHELL" doesn't exist. Only one can possibly execute successfully.
Any idea why, and any idea where I can start the agent so that the environment variables are *not* overwritten by gnome-keyring-agent.
Someone, either you or the user, just needs to disable the gnome-keyring-daemon's ssh module. It can be un-checked in the gnome-session-properties UI (which will survive system updates) or by removing or making unreadable the gnome-keyring-ssh.desktop file (which will not).