Re: [Duplicity-talk] Why -oUserKnownHostsFile=/dev/null

[Peter Schuller]

> >> I think the solution would be to go back to secure as default, then
> >> error out if SSH known-hosts interaction causes any kind of issue.  I
> >> don't see any problem with that, other than the fact that it may error
> >> out when unattended.
> >>
> >> That way users can issue the two ssh options via --ssh-options.  No new
> >> options need to be added and users have a full set of capabilities.
> >>
> >> Opinions?
> > 
> > Sounds good to me. I do like secure-by-default behavior. But I certainly 
> > don't 
> > want it to *block* either; erroring out is the proper course of action IMO.
> > 
> > Do you want a patch for this?
> 
> Yes, Thanks!

So I finally got around to this. As far as I can tell, failure cases
such as using the wrong password or otherwise failing authentication,
are just aborted and re-tried like any other failure.

So to bring the host key case into line with that behavior, all I did
was remove the default ssh options and make some slight changes to
make the error message more explicit in case of this particular
failure, to say the failure was due to host key checking. Patch is
attached.

Now, above, did you mean you wanted to have duplicity fail hard rather
than keep trying to re-try until max retries? I would agree with that,
but that seems to be more of a general problem in dealing with
"permanent" failures, not just limited to ssh host keys.

Thoughts?

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

duplicity-hostkey.diff
Description: Text Data

pgpPpCZM4WIZw.pgp
Description: PGP signature