From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
Description of problem:
/etc/X11/xdm/Xsession launches an ssh-agent before it launches the user's
session. Unfortunately, it launches this ssh-agent after running the user's
login scripts, so if the user has a login script which starts an agent and adds
keys to it, the Xsession script overrides that user's ssh-agent.
Here is the command in Xsession that launches gnome-session, ssh-agent, and the
exec -l $SHELL -c "$SSHAGENT /usr/share/apps/switchdesk/Xclients.$1";
It does things in this order:
- launch the user's shell as a login shell, running .login (for tcsh)
- launch ssh-agent
- launch gnome-session (indirectly through Xclients)
The problem with this line being used is that it prevents the user's login from
starting an ssh-agent and authenticating to it at the best opportunity for both
X sessions and terminal logins. There are other solutions that accomplish the
same objective without preventing this solution from working.
See attachment for possible solutions and scripts that interact with this file.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
logging in through gdm with an ssh-agent started in the shell's login script
Actual Results: the login script creates a ssh-agent, but it is overridden by
the one started in Xsession
Created attachment 91491 [details]
proposed new Xsession file
This proposed new Xsession runs the ssh-agent prior to invoking the user's
shell and the appropriate session manager.
It is organized somewhat differently than the original to make sure that:
-the failsafe runs first regardless of the other options
-the ssh-agent runs next before anything else happens
I believe that with this Xsession, someone relying on the behavior of the
earlier Xsession's (before ssh-agent starting was added) or the behavior in 9.0
(with ssh-agent starting) will not see any change.
Starting the ssh-agent at all may change the behavior of some people's oldre
scripts, but those scripts can easily be modified. With the current
configuration, there's no way to fix it within a .login file.
The following code segment in a .login now works with the old Xsession, my
revised Xsession, console terminal login, and remote terminal login:
ssh-add -l >& /dev/null
if ($sshstatus == 2) then
else if ($sshstatus == 1) then
I use a shell script that starts ssh-agent from my .bash_profile.
This script checks if there's running ssh-agent and starts new one if
not. SSH_AUTH_SOCK, SSH_AGENT_PID and one shell variable for internal
use are exported and saved in a temp file. Non-login shells (for X)
read these from it (via .bashrc). When I login on another console or
open new X terminal my ssh keys are available to them. The script also
kills ssh-agent at exit.
This worked and still works without X, but with it in FC1 I have
two ssh-agents (one from X) and no variables exported. When I first
login from XDM I get a dialog to enter my passphrase (If I ssh-add
from the script), but nothing works because the 'exported' variables
are not really exported.
Created attachment 102506 [details]
Patch to xinitrc-3.42-1 Xsession
Patch to xinitrc-3.42-1 Xsession to check is SSH_AGENT_PID is set before
I've reviewed this request, and the attached files. It is a sane
request which I believe is safe and also the right thing to do.
One thing I noticed while adding this request, is that Xsession
and xinitrc share about 80% of their code, however fixes often
get put into one but left out of the other (such as was the case
I'm going to refactor the common code out into a single file which
both of these scripts source in the future, so we don't have
unnecessary code duplication, and bugs getting fixed in only
one place, etc.
Thanks for the suggested fix Daniel, it'll be in xinitrc 4.0.7-1
in rawhide soon.