On Thu, Jun 05, 2008 at 08:55:40AM -0700, Frank Miles wrote: > 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? ssh-add -l > > 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 > > > -- > To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a > subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > > -- "The war on terror involves Saddam Hussein because of the nature of Saddam Hussein, the history of Saddam Hussein, and his willingness to terrorize himself. " - George W. Bush 01/29/2003 Grand Rapids, MI
Attachment:
signature.asc
Description: Digital signature