Keychain use no longer avoids password requirement
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
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