Bug 18069 - Please provide a hook for ssh-agent
Please provide a hook for ssh-agent
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
: FutureFeature
: 21949 21950 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-02 06:14 EDT by Thilo Mezger
Modified: 2014-01-21 17:48 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-31 06:39:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thilo Mezger 2000-10-02 06:14:33 EDT
SSH works best when you let the ssh-agent take control of the key
management.  In order to turn this feature on, you usually start
your GUI as a child of the ssh-agent.

In 6.2, I always changed /etc/X11/xdm/Xsession to this:

gnome)
       exec ssh-agent gnome-session

Of course, for a clean support of the ssh-agent you would want to
enhance switchdesk as well and maybe control it via a variable in
/etc/sysconfig/* like SSH_AGENT="yes|no".
Comment 1 Daniel Roesen 2000-10-03 14:26:32 EDT
I wouldn't subscribe to "SSH works best" (then it's most convenient, yes, but
also has security implications as you have to trust _all_ child processes of the
ssh-agent to not be trojaned and/or leak you secret key anywhere).

But I would vote for hooks to easily integrate ssh-agent into the system, yes.
Comment 2 Nalin Dahyabhai 2000-10-04 19:08:46 EDT
Probably this would be best done in switchdesk itself with an added flag.
Comment 3 Fabian Kroenner 2000-10-05 08:56:13 EDT
I second this feature request.

The security issue is not in ssh-agent itself, but comes to play when user 
executes ssh-add (i.e. via GNOME session-manager) manually. I merely oppose 
transparently integrating ssh-agent/ssh-add for the uneducated user.
Comment 4 David Woodhouse 2000-10-05 16:17:11 EDT
The way I'm doing this at the moment is to add a script
/etc/X11/xinit/xinitrc.d/ssh-agent:

#!/bin/sh
# (c) 2000 Red Hat, Inc.
export SSH_ASKPASS=/usr/libexec/ssh/gnome-ssh-askpass
eval `/usr/bin/ssh-agent`

Making this configurable by the user, and making it use the correct askpass, is
left as an exercise for the reader.
Comment 5 Bernhard Rosenkraenzer 2000-12-12 11:45:05 EST
*** Bug 21950 has been marked as a duplicate of this bug. ***
Comment 6 Bernhard Rosenkraenzer 2000-12-12 11:48:28 EST
I'm not sure switchdesk is the right place to handle this, since the switchdesk
stuff is overwritten every time the user decides to use a different desktop.
xinitrc?
Comment 7 Ed Bailey 2000-12-12 12:08:34 EST
Maybe something similar to the following should be put in /etc/X11/xinitrc (this
is my hacked ~/.Xclients file, but it should be enough to get my point
across...):

if [ -e "/usr/bin/ssh-agent" ]; then
    AGENT="/usr/bin/ssh-agent"
else
    AGENT=""
fi

if [ -e "$HOME/.Xclients-$HOSTNAME$DISPLAY" ]; then
    exec $AGENT $HOME/.Xclients-$HOSTNAME$DISPLAY
else
    exec $AGENT $HOME/.Xclients-default
fi

Comment 8 Nalin Dahyabhai 2001-01-10 19:21:20 EST
I've taken various stabs at this over the last month or so.  Attempting to start
the agent when you don't have keys or already have an agent running is a waste
of time.  The subsequent ssh-add invocation which would be needed should be
skipped if you already have an agent running with the keys in your files.... and
it just keeps getting more complicated from there.  I'll leave this bug ID open
in case something more elegant springs into someone's mind.
Comment 9 Mike A. Harris 2001-02-17 11:41:15 EST
*** Bug 21949 has been marked as a duplicate of this bug. ***
Comment 10 Matthew Miller 2001-03-11 11:03:03 EST
add cc me
Comment 11 Need Real Name 2001-03-27 17:37:02 EST
To see if ssh-agent is running, test for $SSH_AGENT_PID.

if [ -z "$SSH_AGENT_PID" ]
then
  eval `/usr/bin/ssh-agent` > /dev/null 2> /dev/null
fi

To see if any keys are loaded in the agent, run "ssh-add -l" and grep for "no 
identities".  A little less clean but works fine.  E.g.,

  (/usr/bin/ssh-add -l | /bin/grep 'no identities') \
        && /usr/bin/ssh-add $HOME/.ssh/identity \
        && /usr/bin/ssh-add $HOME/.ssh/id_dsa



Comment 12 Nalin Dahyabhai 2001-04-02 20:09:35 EDT
The suggestion from dbarrett is pretty close to what I started cooking up, but
it would need to run ssh-add properly to be the most useful.  But then you'd
want to only run ssh-add for keys which weren't already in the agent's list of
keys, and shut down the agent when the session ended, but only if .Xclients
started the agent.  The result looked something like this:

#!/bin/bash

# Created by Red Hat Desktop Switcher

SWITCHDESK_AGENT_PATH=
if [ -x /usr/bin/ssh-agent ] ; then
    if [ -z "$SSH_SWITCHDESK_AGENT_PATH_PID" -a -z "$SSH_AUTH_SOCK" ] ; then
        if [ -r $HOME/.ssh/identity -o $HOME/.ssh/id_dsa ] ; then
            SWITCHDESK_AGENT_PATH="/usr/bin/ssh-agent -s"
            eval `$SWITCHDESK_AGENT_PATH`
        fi
    fi
fi

if [ -n "$SSH_SWITCHDESK_AGENT_PATH_PID" ] ; then
    if [ -f $HOME/.ssh/id_dsa ] ; then
        SWITCHDESK_FINGERPRINT=`/usr/bin/ssh-keygen -dlf $HOME/.ssh/id_dsa.pub |
awk '{print $2}'`
        if ! /usr/bin/ssh-add -l | grep -q $SWITCHDESK_FINGERPRINT ; then
            /usr/bin/ssh-add $HOME/.ssh/id_dsa < /dev/null
        fi
    fi
    if [ -f $HOME/.ssh/identity ] ; then
SWITCHDESK_FINGERPRINT=`/usr/bin/ssh-keygen -lf $HOME/.ssh/identity | awk
'{print $2}'`
        if ! /usr/bin/ssh-add -l | grep -q $SWITCHDESK_FINGERPRINT ; then
            /usr/bin/ssh-add $HOME/.ssh/identity < /dev/null
        fi
    fi
fi

if [ -e "$HOME/.Xclients-$HOSTNAME$DISPLAY" ]; then
    $HOME/.Xclients-$HOSTNAME$DISPLAY
else
    $HOME/.Xclients-default
fi

if [ -n "$SWITCHDESK_AGENT_PATH" ] ; then
    $SWITCHDESK_AGENT_PATH -k
fi

Comment 13 Need Real Name 2002-02-05 09:04:52 EST
Hello,

I have a simple problem and what I read here seems fairly close to what I want
to achieve. However, all this discussion seems to be back to the RH6.2 -7.0
time. I am running 7.2 here.

Here is my problem:
I want to have ssh-agent and ssh-askpass started automatically when I log in. I
followed the procedure given in the RH manual (.Xclient modification and Gnome
Control Center) BUT... It does not work properly for me...
The reason is fairly simple, I start on init 5, not on init 3 (with init 3 in
inittab it works, with init 5, the passphrase is never asked...)
Moreoevr, this would work well as long as I would use Gnome but if I use KDE...
what does happen there?

So here is my questions:
Have the conclusion of the discussion under the label Bug 18069 been included
somehow in RedHat 7.2?
How can I get the passphrase asked systematically (or to be more precise, if ssh
is used by the user) under init 5 and for any GUI (KDE, Gnome, Motif...)

Daniel
Comment 14 Kenn Humborg 2002-04-14 17:17:42 EDT
Surely this is a much better way to do it:

   http://sourceforge.net/projects/pam-ssh/

From their README:

   This PAM module provides single sign-on 
   behavior for UNIX using SSH.  Users are 
   authenticated by decrypting their SSH 
   private keys with the password provided 
   (probably to XDM).  In the PAM session phase, 
   an ssh-agent process is started and keys are added.
Comment 15 Bernie Innocenti 2005-01-02 06:35:45 EST
I tried pam-ssh and I'm not completely satisfied 
with it. 
 
Its main purpose is authenticating users based 
on the SSH passphrase, and it loads the 
keys as a side-effect.  With this setup, users 
without an SSH key can't login. 
 
Maybe this one? 
 
  http://sourceforge.net/projects/pam-ssh-agent/ 
 
Comment 16 Tomas Mraz 2005-03-31 06:39:20 EST
In the current FC releases the ssh-agent is started by default from the gdm when
starting the user's session.
Comment 17 Bernie Innocenti 2005-03-31 19:36:49 EST
(In reply to comment #16)
> In the current FC releases the ssh-agent is started by default from the gdm when
> starting the user's session.

Two problems:

 - console logins and kdm users are hopeless;

 - Encripted keys must still require typing
   the password a second time.  pam_ssh_agent
   would solve this.
Comment 18 Matthew Miller 2005-03-31 20:07:56 EST
> - console logins and kdm users are hopeless;

I don't think you mean "hopeless". :)

But anyway, for console logins, this is probably best set up in individual
dotfiles. And kdm is kind of a weird case in Fedora (since gdm is the default
even for KDE users).

> - Encripted keys must still require typing
>   the password a second time.  pam_ssh_agent
>   would solve this.

Except, it's not "the password" -- it's a passphrase, and if you're going
to make that exactly the same as your password and load it into ssh agent
at login, you might as well not have a passphrase at all.
Comment 19 Tomas Mraz 2005-04-01 01:42:16 EST
I wouldn't say that to have the passphrases the same as login password is the
same as not to have a passphrase at all however it's significantly weaker than
having passphrase differing from login password.
And I don't like that the user would have in case of pam_ssh_agent immediately
unlocked his keys without an explicit action. This weakens the security even more.
Comment 20 Bernie Innocenti 2005-04-01 18:52:21 EST
(In reply to comment #18)
> > - console logins and kdm users are hopeless;
> 
> I don't think you mean "hopeless". :)

:-)  I always make confusion when choosing between
expressions that translate similarly even though
they have different semantics in English!
Would "left in the cold" be ok?

> But anyway, for console logins, this is probably best set up in individual
> dotfiles. And kdm is kind of a weird case in Fedora (since gdm is the default
> even for KDE users).

Actually, I use GDM with KDE on Fedora because
a session started from KDM doesn't run ssh-agent
and also has incorrect font aspect retio.


> Except, it's not "the password" -- it's a passphrase, and if you're going
> to make that exactly the same as your password and load it into ssh agent
> at login, you might as well not have a passphrase at all.

Uh? The unencrypted key is stored in locked memory.
How would that be less secure than running ssh-add
manually and typing a different password?

I think Linux badly needs improvements to be fully
single-sign-on.  I hate typing my password 4-5
times just to read my mail and log into intranet
applications when the computer should already
know who I am since the long.

Both Mac OS X and Windows make life in enterprise
environments easier than this.  This can be done
without surrending security (Kerberos, system-wide
encrypted password wallet, NTLM auth, etc.).

Sorry for this usability rant, I know it's
off-topic here.
Comment 21 Matthew Miller 2005-04-01 23:43:16 EST
If someone just needs to know your password to access your account and unlock
your key, you might as well not have a passphrase on the key, because it's
serving no purpose. Having a different passphrase at least means that someone
would need to know your password *plus* the passphrase. If you don't think
that's important, don't set a passphrase.
Comment 22 Bernie Innocenti 2005-04-02 10:56:29 EST
Hmmm... A passphrase is by definition a secret
you should never give away.  If you type it too
often, you increase the risk of letting someone
read it over your shoulder.

Accounts are more often compromised *without* the
passphrase.  The superuser can read files in my
home directory, but he still wouldn't be able
to use my ssh or gpp keys when they are encrypted.

Using 10 different passphrases to log in
wouldn't make any difference when private
information is stored on disk in cleartext
format.

I know many Linux users who use empty passphrases
for their ssh keys just because setting up
ssh-agent and running ssh-add is too inconvenient.

But I bet *no* Mac OS X user intentionally
disables secure password storage, which is
enabled by default system-wise.

So, Mac OS X makes secure behaviour more
convenient for the user, hence achieving
greater security.

Note You need to log in before you can comment on or make changes to this bug.