ssh-agent tips for remote and cron jobs

I've been told that the use of ssh-agent is not completely obvious, even after people read the man page. Here are a few helpful hints that apply to some common patterns of computer usage.

Users who start X sessions with startx (or other wrappers around xinit such as the Sun openwin command)
As indicated in the man page for ssh-agent it is easiest simply to let the agent run the X startup. E.g., instead of
startx [args...]
simply type
ssh-agent startx [args...]
The agent will terminate when the session terminates.

Users who start X sessions with xdm (including Solaris ``OpenWindows'' sessions)
xdm typically runs a shell script named ~/.xsession (except on Suns where they never left the past and still use the ancient filename ~/.xinitrc). ssh-agent can be incorporated in the startup by doing something like this:
	mv -i ~/.xsession ~/.xsession.script
	cat > ~/.xsession
	#! /bin/sh
	/path/to/your/ssh-agent $HOME/.xsession.script
	^D
	chmod +x .xsession
	
Henceforth xdm will run ssh-agent which will run the X session script. The agent will terminate when the session terminates.

Users who start X sessions with Red Hat Linux 7.3 through 9.0
This is much like the above case except that the startup script is named ~/.Xclients instead of ~/.xsession. Note that this makes use of my fsa script in a fashion that supports logins through the login widget of the gnome display manager as well as text-based logins on virtual consoles that are not running the X server.
	#! /bin/bash

	# see if there is already an agent, else start one
	eval `fsa -f sla`

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

Users who start X sessions with Red Hat Linux 5.x through 7.2
This is much like the above case except that the startup script is named ~/.Xclients instead of ~/.xsession. Things are more complicated if you are running more than one X server (presumably of different bit depths) on different virtual consoles. I have a solution for this which makes use of my fsa script.

Users who start X sessions with CDE
In one case I have successfully adapted the CDE startup scripts to run ssh-agent and set the environment such that all child shells inherit connections to the agent. I'm not sure that the agent terminated when the session terminated.

Conceptually, the setup for CDE is similar to the above example for xdm. It was not fun, however, and with no apology I leave this as an excercise for the reader.


Non-X users; e.g., traditional Unix logins, rlogin and telnet sessions
Users of Bourne-like shells can place
		eval `ssh-agent`
	
into their ~/.profile (or some other login startup file).

Users of C-like shells can place

		eval `ssh-agent -c`
	
into their ~/.login (or some other login startup file).

Note that if the agent is started in this fashion it will background itself and persist until explicitly killed. Killing it might be a suitable thing to do in a ~/.logout (or some other logout procedure).

Also note that if this is a rlogin or telnet session then the passphrase for authorizing ssh-agent to hold the key will be transmitted in the clear over the net. It makes more sense to be using ssh-agent and ssh on the machine from which such sessions originate.


one-time users of ssh
If ssh is only to be used very rarely then the above startup lines for shell users can simply be typed interactively. Remember that the agent will persist until killed.

users of F-secure ssh on Windoze or Macs
For now, consider yourself a non-X user above.

Ideally the entire set of steps of key generation as well as the running of the equivalent of ssh-agent would be done on the PC or Mac. That way the private key would be made available to the command line session on the Unix host whence the CVS access will actually occur. Whether or not this is possible remains to be investigated. Volunteers?


Back to Steve's ssh page.
Steve Allen <sla@ucolick.org>

2000-07-20