Gordon Messmer wrote:
On 03/28/2013 07:00 AM, m.roth@5-cent.us wrote:
Most of my users are on kde, as am I (I really don't like gnome). I've
got one on gnome, though, CentOS 6.4, and I have a problem: I have to start
an agent running ->on login<-, so that the same one is in the
environment
of every term window he opens.
That would be the normal configuration.
In kde, no problem, I modify /etc/X11/xinit/xinitrc-common so that code
in there calls our (newer) ssh-agent instead of the stock one. (And, of course, it's killed on logout, and there's only one running,
not one every time that never go away unless killed manually.)
You're already making things more complicated than they should be. The
ssh agent is supposed to be the parent process of your login session. That is, your login session should be:
ssh-agent startkde or: ssh-agent gnome-session
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.
With GDM, you'd modify the session file in /usr/share/xsessions. You'd
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? #$%^&*$%^&*($%^&*($%^&*(%^&*()_+
No matter what I open it in, it keeps showing up with garbage chars.
So I look at /etc/gdm, as I said, and I see it sourcing /etc/X11/xinit/xinitrc-common, where I've got it set to reference our agent. Then I go further down, and see <snip>*************** case "$1" in failsafe) exec -l $SHELL -c "xterm -geometry 80x24-0-0" ;; gnome|gnome-session) # lack of SSH_AGENT is intentional, see #441123. though # the whole thing should really happen in xinitrc.d anyway. exec -l $SHELL -c gnome-session exec /bin/sh -c "exec -l $SHELL -c "gnome-session"" ;; kde|kde1|kde2) exec $CK_XINIT_SESSION $SSH_AGENT /bin/sh -c "exec -l $SHELL -c "startkde"" <snip>***************
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"
prefix the "Exec" line with "ssh-agent ", and be done. As those files
would be <snip>
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. 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.
Ok, I followed the guy's instructions, but a) I'm afraid to let the keyring not run, 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. Any idea why, and any idea where I can start the agent so that the environment variables are *not* overwritten by gnome-keyring-agent.
mark
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).
Gordon Messmer wrote:
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.
<snip> 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"
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.
Anyway, my hack which works neatly is to create a three line shell script that goes into the users .<shellrc> file, whose contents are: #!/bin/sh export SSH_AGENT_PID=`ps -fu $USER | awk '($0 ~ //usr/bin/piv-ssh-agent/) { print $2;}'` export SSH_AUTH_SOCKET=`awk '($0 ~ //tmp/ssh-/ ) { print $NF;}' /proc/$SSH_AGENT_PID/net/unix `
It's a hack, but a clean hack, and I'm not wasting more hours, and my user is up and running.
mark
On 03/29/2013 12:16 PM, m.roth@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.
-
Gordon Messmer -
m.roth＠5-cent.us