[prev in list] [next in list] [prev in thread] [next in thread] 

List:       secure-shell
Subject:    Re: ssh, HP-UX 10.20, dtwm, help!
From:       Martin Frost <me () CS ! Stanford ! EDU>
Date:       1998-06-29 19:18:10
[Download RAW message or body]

 > Date: 23 Jun 1998 21:11:06 +0200
 > From: Helmut Waitzmann <Helmut.Waitzmann@studbox.uni-stuttgart.de>

 > In your .dtprofile in your home directory, you could insert the
 > following command:
 > 
 >     eval `ssh-agent -s`

 > Now, as ssh-agent has been started during the CDE startup, it
 > should be killed, when exitting from CDE.  To do this, create a
 > file named 'sessionexit' in your '"$HOME"/.dt/sessions'
 > directory, and put the following contents into it:
 > 
 >     #!/bin/sh
 >     eval` ssh-agent -k -s`
 > 
 > Now, make it executable:
 > 
 >     chmod a+x "$HOME"/.dt/sessions/sessionexit
 > 
 > This file will be executed during CDE logout.
 > 
 > 'ssh-agent -k' will kill the agent (it uses the 'SSH_AGENT_PID' environment
 > variable to find it) and print shell commands to stdout that will
 > unset the SSH_AUTH_SOCKET and SSH_AGENT_PID environment
 > variables.
 > 
 > Unfortunately, as 'sessionexit' is executed by a subprocess,
 > the environment variables will only be unset in the
 > process executing the 'sessionexit' shell script.
 > 
 > But I assume, this is not a lack of security.  Or do I miss
 > something here?


The environment variables are not a security issue once the ssh-agent
process is gone (along with any identification information it had stored in
its memory).


Note, however, that to make use of that identification information while
ssh-agent *is* still running, you don't have to be running as a child (or
descendent) of ssh-agent.  That's convenient, but unfortunate for security.

If, after you've done ssh-add, someone breaks into your account, they can
then use your identification info from ssh-agent to log into other machines
that you've authorized yourself to log into, without a password.

I was hoping that only children of ssh-agent would be allowed this sort of
access, but I guess this is no worse than having a Kerberos ticket in a
file readable by other instance of the same user.


Martin

[prev in list] [next in list] [prev in thread] [next in thread]