FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 06-05-2008, 03:55 PM
Frank Miles
 
Default 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
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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-05-2008, 05:54 PM
Eduardo M KALINOWSKI
 
Default Keychain use no longer avoids password requirement

Frank Miles escreveu:
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!


Take a look at: http://www.debian.org/security/key-rollover/


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-05-2008, 07:28 PM
Alex Samad
 
Default Keychain use no longer avoids password requirement

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
 
Old 06-06-2008, 05:10 AM
Daniel Burrows
 
Default Keychain use no longer avoids password requirement

On Thu, Jun 05, 2008 at 08:55:40AM -0700, Frank Miles <fpm@u.washington.edu> was heard to say:
> Any clues - including references to man pages possibly overlooked - would be
> appreciated. TIA!

In any order you choose, but ASAP, you need to:

(a) Subscribe to debian-security-announce:
http://lists.debian.org/debian-security-announce/
(b) Read this security bulletin:
http://www.debian.org/security/2008/dsa-1576

The short answer is that the new openssh has disabled your keys to keep
people from breaking into your computer, but this change is not
foolproof and there might be other changes you need to make in order to
protect yourself depending on what other services run on this backup
machine or on your other Debian machines (if you have any).

Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-06-2008, 05:12 AM
Daniel Burrows
 
Default Keychain use no longer avoids password requirement

On Thu, Jun 05, 2008 at 10:10:11PM -0700, Daniel Burrows <dburrows@debian.org> was heard to say:
> In any order you choose, but ASAP, you need to:
>
> (a) Subscribe to debian-security-announce:
> http://lists.debian.org/debian-security-announce/
> (b) Read this security bulletin:
> http://www.debian.org/security/2008/dsa-1576

Also this one:

http://www.debian.org/security/2008/dsa-1571

Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 08:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org