deja-dup always asks for SSH password

[Christoph Leuzinger]

I'd like to use SSH authentication identity files when doing backups to a remote host.

This means there should be a possibility in the preferences menu to choose if the SSH connection is to be authenticated by using a password or by using an authentication identity file. The preferences window should provide a field where the path to the authentication identity file can be entered, if authentication by identity file is chosen.

Furthermore the SSH backend should pass the --ssh-askpass flag to duplicity only if authentication by password has been chosen. Accordingly if authentication by identity file is chose the SSH option "IdentityFile <id-path>" should be passed.

If the identity file is secured by a password the gnome-keyring/ssh-agent mechanism should be able to handle the unlocking of the identity file, so this might not be a problem for deja-dup.

[Christoph Leuzinger (leuzi-trash)]

I've put together a patch against rev. 251 that adds the necessary widgets to the preferences dialog and stores the additional values in the gconf registry. I also modified the BackendSSH to use these settings, i. e. to not ask for a password if an identity file is to be used.

I tested the patched version and it works fine on my Intrepid/amd64 box. The patch has some rough edges, though, so if you think it might make it into a future release, I'll do some cosmetics. Also, I'm new to Vala and I appreciate feedback.

Last but not least: Thanks for creating deja-dup, I think it is quite a decent backup interface for GNOME.

[Michael Terry (mterry)]

Thanks for the bug report and patch! You win the prize for being the first to submit a patch to Deja Dup. Whoo!

First, the patch. It's a very good patch. A few comments:

1. Rather than create a new ConfigFile class, I would just make the existing ConfigFolder class more generic (rename to ConfigFile and take an argument for what kind of file to select).

2. When adding gconf keys, you also need to add the new keys to the file data/deja-dup.schemas with a description.

3. In BackendSSH.vala, you added an if block around some existing code, but didn't indent that code. It made the patch easier to read (less noise), but the code should be indented.

However... I don't think this patch is the right approach. I don't see why the user should have to decide before hand if they want to use the identity file. It creates a more complicated preferences dialog, and users aren't used to answering that question. When you connect to an ssh server on the console, ssh figures out if you have an identity file for the server and only asks you if it needs to. I think Deja Dup should do the same thing.

That might mean adding code to duplicity that signals that a password is needed. Maybe we can pass it a flag like --ssh-never-ask-pass and if it fails with an error like "ERROR 53 Need SSH password" then we would throw up a dialog and ask.

[Christoph Leuzinger (leuzi-trash)]

Thanks for your feedback!

ad 1.: That should be pretty straightforward. I somehow failed to notice the ConfigFolder class when creating the ConfigFile class.

ad. 2., 3.: I consider these to be some of the "rough edges". Thanks for pointing it out, though.

Concerning the overall approach: I'm not sure if the best method to determine the SSH authentication method is to go with trial and error. There are quite a number of possibilities, some of which are:

a) There is no identity file on the source host. This is straightforward: use authentication by password.

b) There is an identity file on the source host, but no public key on the target host. This would be covered by the duplicity modification you propose.

c) There is more than one identity file on the source host, and/or their location in the file system is not necessarily known a priori. In this case, there is no need to use password authentication, but to ask the path to the identity file to be used.

You might argue that case c) is not very common, but I think it's important to keep the authentication methods that SSH provides, and it does provide the -i flag.

Generally I don't like the idea of guessing the right authentication method, as this is something that I want to control strictly. Also I don't think the SSH preferences get too complicated. Users might get confused about the identity file path, but if it contains a sensible default value (which can be guessed, if you like :-)), I think this shouldn't be much of a problem. They're using SSH after all.

[Michael Terry (mterry)]

Fixed in trunk by outsourcing SSH connections to gvfs (we always pass duplicity a local FUSE path now -- except for s3). I believe that gvfs does the right thing.

[Audrius Meskauskas (v-audrius)]

This does not look very much a solution as gvfs seems not supporting the key based authentication either - at least as much as I can configure with gigolo 0.4.1. Allows to set server, port and username - that is all. From the gvfs documentation, it supports URI, and the uri can be something like sftp://<email address hidden>/ but I think seems no support for SSH keys. I will also compile and use this patched version, thanks for the great work!

Password based authentications are disabled on our servers for security reasons, only keys are used.

[Carl van Tonder (carlvantonder)]

@Audrius, agreed.

Can someone explain how to set an SSH identity file for gvfs?

If that's not possible, I believe this bug should be reopened.