Keychain use no longer avoids password requirement

[Frank Miles <fpm@u.washington.edu>]

I have a simple backup system : a remote system periodically tars some important
data, and notifies a server that it should read those files.  The server then
tries to read the files:

	su - --command="scp URL:/path/filename.tjz /backup-path/filename.tjz" backupUser

Until mid-May, this was working great.  Keychain had been invoked so that this 
could operate without user intervention.  However now the scp operation is
asking for a password, which the script does not have.  If done manually, the
operation works.

In trying to resolve this, I've not found how to interrogate the ssh-agent to
determine what keys it has access to.  So first question - is there some way
to determine that?

One probably-more-than-a-coincidence is that the failure began on rebooting the
remote system, probably due to a kernel/security update.  It's running Etch/2.6.18.
As it would seem to be the server rather than the remote system that was rebooted,
I'm mystified as to why any kernel change (and these are self-compiled kernels)
on the remote system would have any effect on this operation.

Any clues - including references to man pages possibly overlooked - would be
appreciated.  TIA!

	-f