Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Run ssh-agent and Aqua without additional software UNIX
There are programs like SSH Agent or keychain that provide a nice way of managing keys in OS X. But I managed to work around the fact that, with Aqua, you cannot start a session under something else like .Xclients (i.e. ssh-add would only work for one session at a time) without the need for an additional software.

This little script can be run from within your .bashrc, or sourced if put in a separate file. I source it from within my .bashrc. The script is not the best code, but it does the job fairly well, and I hope it will work for future versions of ssh too.
#!/bin/bash

#
# Toni Magni Wed Nov 6 18:37:15 BRST 2002
# Find out if ssh-agent is running, and if so, export the glob vars.
# Source from .bashrc or so.
#

SSH_AGENT_PID=`ps x| grep ssh-agent | grep -v grep | awk '{print $1}'`;
if [ -n "$SSH_AGENT_PID" ]; then
export SSH_AGENT_PID;
SSH_AUTH_SOCK=/tmp/`ls --co=never /tmp | grep ssh`;
SSH_AUTH_SOCK=$SSH_AUTH_SOCK/`ls --co=never $SSH_AUTH_SOCK`;
export SSH_AUTH_SOCK;
else
eval `ssh-agent`;
ssh-add;
fi
[Editor's note: I haven't tested this hint myself.]
    •    
  • Currently 3.00 / 5
  You rated: 1 / 5 (2 votes cast)
 
[6,724 views]  

Run ssh-agent and Aqua without additional software | 6 comments | Create New Account
Click here to return to the 'Run ssh-agent and Aqua without additional software' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
already an app to do this
Authored by: laz on Dec 03, '02 12:24:15PM
An app called keychain (not to be confused with Apple's keychain) that does this can be found at http://www.gentoo.org/proj/en/keychain.xml.

[ Reply to This | # ]
A better way... sshLogin
Authored by: ddribin on Dec 04, '02 01:31:11AM
Take a look at sshLogin. It works great! It modifies the OS X equivalent of .Xclients and provides a OS X native dialog box to ssh-add. It uses the standard OpenSSH ssh-agent, but they figured out a way to set environement variables at login time. Very handy. -Dave

[ Reply to This | # ]
how to make it so much easier
Authored by: theegor on Dec 04, '02 11:14:19AM

All of these solutions are over-kill. ssh-agent already offers a fine solution. I run the following script in my .bash_profile:

# Start an ssh-agent for global use (and detect agent-forwarding).
if [ -z "$SSH_AUTH_SOCK" -o ! -p "$SSH_AUTH_SOCK" ] ; then
export SSH_AUTH_SOCK=/tmp/ssh-yoda-agent
if [ ! -p "$SSH_AUTH_SOCK" ] ; then
ssh-agent -a $SSH_AUTH_SOCK
fi
fi

The first time you open a terminal, or login via ssh, the agent will start (unless it detects agent forwarding). All of your ssh clients will automatically use the same agent unix-domain bind address. Thus it is global throughout the system for your user account. No need to worry about race conditions either ... ssh-agent avoids them.

If you use Aqua apps which need environment variables for ssh, then set them in ~/.MacOSX/environment.plist like so:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CVS_RSH</key>
<string>/usr/bin/ssh</string>
<key>SSH_AUTH_SOCK</key>
<string>/tmp/ssh-yoda-agent</string>
</dict>
</plist>

Re-login to cause Aqua to recognize the new environment variables.

You don't need a program to run at login time to dynamically set SSH_AUTH_SOCK. since my solution always uses the same filename for SSH_AUTH_SOCK.

Notice how simple this is? Read the ssh-agent man page if you don't agree ...



[ Reply to This | # ]
how to make it so much easier AND SECURE :)
Authored by: fredcondo on Jan 25, '03 05:29:42PM

The method above is great, except that it probably creates the socket with 755 permissions. The pipe should be readable only by you. I use this script to implement your suggestion. I know it seems a little fancy; I got the basic idea from a hint somewhere, and was already using the script. When I made the path of the socket file invariant, I also added the three umask commands to protect the socket from prying eyes.

#!/bin/sh -
# checks for running ssh-agent, and starts one if not running

SSH_ENV=$HOME/.ssh/environment.setup
PIPE=some_made_up_string
function start_agent {
echo -n "Initializing new ssh-agent ... "
touch ${SSH_ENV}
ssh-agent -a /tmp/$PIPE > ${SSH_ENV}
. ${SSH_ENV} > /dev/null

ssh-add $HOME/.ssh/id_rsa $HOME/.ssh/id_dsa && \
ssh-add -l

}

OUMASK=`umask`
umask 077
if [ -f ${SSH_ENV} ]; then

. ${SSH_ENV} > /dev/null
ps ${SSH_AGENT_PID} | grep "ssh-agent" > /dev/null 2>&1

if [ $? -ne 0 ]; then
start_agent
fi

else
start_agent
fi
umask $OUMASK



[ Reply to This | # ]
how to make it so much easier
Authored by: thvv on Dec 24, '03 09:25:14AM
The hint as posted did not work for me on Panther. Three things were missing.. backticks around the ssh-agent, -s on the ssh-agent, and -S instead of -p in the tests.


# Start an ssh-agent for global use (and detect agent-forwarding).
if [ -z "$SSH_AUTH_SOCK" -o ! -S "$SSH_AUTH_SOCK" ] ; then
export SSH_AUTH_SOCK=/tmp/ssh-yoda-agent
if [ ! -S "$SSH_AUTH_SOCK" ] ; then
`ssh-agent -a $SSH_AUTH_SOCK -s`
fi
fi


[ Reply to This | # ]
Run ssh-agent and Aqua without additional software
Authored by: kidtexas on Jul 19, '04 04:10:11PM
After trying out several of the GUI versions of ssh-agent, I decided to pursue the command line route. Here is a copy of my .login (tcsh) that does the following: 1. checks to see if the ssh-agent sock is up and running - if its not, it starts it. 2. if the sock is there, but the file that holds the PID of ssh-agent is not, it recreates that pidfile 3. sets an env variable if the pidfile is there.

set sshAgent=/usr/bin/ssh-agent
set tmpFile = exportAgentEnv
set PIDFile = $HOME/.ssh/sshAgentPID

# Start an ssh-agent for global use
if ( -x "/usr/bin/ssh-agent" ) then
	if ( ! -e "$SSH_AUTH_SOCK" ) then	
		set OrigUmask=`umask`
		umask 077
		$sshAgent -a $SSH_AUTH_SOCK -c | head -2 > $tmpFile
		source $tmpFile
#		tail -n 1 $tmpFile > $PIDFile
		echo $SSH_AGENT_PID >$PIDFile
		rm $tmpFile
		echo "ssh-agent started [${SSH_AGENT_PID}]"
		umask $OrigUmask
		ssh-add
	endif
endif

if ( -e "$SSH_AUTH_SOCK" ) then	
	if ( ! -e "$PIDFile" ) then
		set sshpid=`ps x| grep ssh-agent | grep -v grep | awk '{print $1}'`
		echo $sshpid> $PIDFile
	endif
endif

# Read in ssh-agent PID
if (-e $PIDFile) then
	set sshpid=`head $PIDFile`
	setenv SSH_AGENT_PID $sshpid
#	source $PIDFile
endif
On logout, I have the following script running from a logout hook:

#! /bin/sh
if [ -e "$HOME/.ssh/sshAgentPID" ]; then
        SSH_AGENT_PID=`head $HOME/.ssh/sshAgentPID`
        echo "$SSH_AGENT_PID"
        echo "killing ssh agent [${SSH_AGENT_PID}]"
        kill $SSH_AGENT_PID 
        rm $HOME/.ssh/sshAgentPID
fi
I decided to implement the logout hook as detailed in the 3 part ssh-agent tutorial on this site. These 2 scripts were also adapted so they could be called up on the command line. The logout can be run exactly as is. The start script was adapted for sh (instead of csh):

#!/bin/sh

sshAgent=/usr/bin/ssh-agent
tmpFile=exportAgentEnv
PIDFile=$HOME/.ssh/sshAgentPID


# Start an ssh-agent for global use
if [ -x "/usr/bin/ssh-agent" ]; then
	if [ ! -e "$SSH_AUTH_SOCK" ]; then	
		OrigUmask=`umask`
		umask 077
		$sshAgent -a $SSH_AUTH_SOCK -s | head -2 > $tmpFile
		source $tmpFile
#		tail -n 1 $tmpFile > $PIDFile
		echo $SSH_AGENT_PID >$PIDFile
		rm $tmpFile
		echo "ssh-agent started [${SSH_AGENT_PID}]"
		umask $OrigUmask
		if [ -e $PIDFile ]; then
			sshpid=`head $PIDFile`
 			SSH_AGENT_PID=$sshpid
		 	export SSH_AGENT_PID
		fi
		ssh-add
	fi
fi

if [ -e "$SSH_AUTH_SOCK" ]; then	
	if [ ! -e "$PIDFile" ]; then
		sshpid=`ps x| grep ssh-agent | grep -v grep | awk '{print $1}'`
		echo $sshpid> $PIDFile
	fi
fi

if [ -e $PIDFile ]; then
	sshpid=`head $PIDFile`
 	SSH_AGENT_PID=$sshpid
 	export SSH_AGENT_PID
#	source $PIDFile
fi
This setup is also compatible with ssh-agent -k. While the above mentioned 3 part ssh-agent tutorial on this site is more integrated (the agent sock changes with each startup and is integrated with keychain) as a whole into the OS X experience, my setup is a little more terminal friendly. One does not have to be logged into the GUI for it to work, and one can also start and stop it at will - enabling one to hook into the sleep mechanism using other utilities if desired. Anyway, the main reason I was posting it is because these scripts do work with tcsh and os x and offer another option to the others mentioned.

[ Reply to This | # ]