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

[Kenneth Loafman]

Peter Schuller wrote:
>>>> 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?

I think for now the patch will work.  It won't take that long to re-try
until max.  Until we have a mechanism for permanent failure, this is the
best way to go.

Thanks for the patch.  Good detail on the error messages!

...Ken

signature.asc
Description: OpenPGP digital signature