Home » CentOS » A-gnome-oyences
CentOS 5 Comments

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. 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.) /etc/gdm/Xsession *says* that it sources that file, so it should be running when he logs in. I’ve just had him log out and log back in, , and no matter what, it just ain’t running.

So, gnome fans, how do I get that to work? Edit /etc/gdm/custom.conf? Edit something else? gconftool-2 (gahhhh)?


5 thoughts on - A-gnome-oyences

  • That would be the normal configuration.

    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

    You get just one, and it closes when the session ends. You *can* set it up otherwise, but other configurations are less reliable and more complex. Don’t make your life difficult.

    With GDM, you’d modify the session file in /usr/share/xsessions. You’d prefix the “Exec” line with “ssh-agent “, and be done. As those files would be over-written during updates, you’d actually probably make a copy, edit that to prefix the command in Exec=, and tell your users to use the session that you’d edited. No problem.

    I’m not sure which DM you’re using, but if it’s actually using xinitrc
    (and thereby, xinitrc-common), that’s already the configuration that’s used. The SSH_AGENT arg is set, and it’s the parent process of 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”.

  • Gordon Messmer wrote:
    got one on gnome, though, CentOS 6.4, and I have a problem: I have to start environment

    ssh agent is supposed to be the parent process of your login session. That is, your login session should be:

    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.

    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
    case “$1” in
    exec -l $SHELL -c “xterm -geometry 80×24-0-0”
    # 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\””
    exec $CK_XINIT_SESSION $SSH_AGENT /bin/sh -c “exec -l $SHELL
    -c \”startkde\””

    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”

    would be

    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.


  • 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.

    “Everything else” is UTF-8 on any sane Unix-like system that supports non-English languages.

    …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.

    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.

    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.

    It’d probably break NetworkManager, at least.

    That’s probably a mistake, but it might be set that way in case “SHELL”
    doesn’t exist. Only one can possibly execute successfully.

    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:
    authentication. when

    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 . 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.


  • I just realized that Xclients.gnome-session.sh is called as:

    … 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

    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)

    Normally you’d want to put environment variables like that into
    .bash_profile instead, so that it’s not called by non-login shells.