Feature request: Support for gpg-agent or ssh-agent

[allanpeda]

I am almost finished migrating my ssh public keys to gpg / gpg-agent and unfortunately BackInTime doesn't seem to support reading passphrases from these agents via SSH_AUTH_SOCK (unless I am mistaken).

I think such a feature would be of tremendous use and is worth considering.

[buhtz]

@allanpeda There is a new forming maintaining team and we do review all issues. Is this problem still relevant for you or did you find a solution?

Tag: Feedback, Feature, External

[allanpeda]

I work around it. I do still think it is a worthwhile feature request.

[buhtz]

How do you worked around it?

[allanpeda]

I use a second public / private key pair.

[andreyfedoseev]

Copied from #2158

Currently, when an SSH profile is created, it requires specifying a private SSH key, which is stored somewhere on the filesystem.

This approach does not work for the scenario when an external SSH agent application is used, such as 1Password, and the SSH keys aren't stored on the filesystem.

Please allow leaving the SSH key field blank when managing SSH profiles.

Currently, I have to create SSH keys on the filesystem only because this is necessary to create an SSH backup profile. And these keys aren't even being used for making backups, because SSH prefers keys from the SSH agent, even if the -i path/to/key option is used to specify a key file explicitly.

[buhtz]

Andrey was asking in #2158 for ssh-agent support. I never used ssh-agent so I can not imagine the steps to implement this. But I am a KeePassXC user. I lack of basic knowledge about that topic.

Andrey can you describe the steps and procedure how you use your password manager and the agent? For example if you simply ssh into the server via shell?

And what is the difference to a keyring (which I also never used) to an ssh-agent?

Regards, Christian

[andreyfedoseev]

can you describe the steps and procedure how you use your password manager and the agent?

I use 1Password password manager to manage my SSH keys. 1Password can act as an SSH agent (more details here and here) which allows using SSH without the need to have the key files stored in the filesystem.

I have the following configuration in .ssh/config

Host *
   IdentityAgent "~/.1password/agent.sock"

This enables 1password as an ssh agent for all hosts.

When an SSH connection is made, the ssh agent is used to provide the private keys (via the socket). It is the responsibility of the ssh agent to unlock the key, if necessary.

When set up correctly, it is possible to simply type ssh my-host and it will log in, without the need to specify path to the key file. This also eliminates the need to store the key files on the filesystem, if the ssh agent allows that (for example, 1password stores the secrets in its own proprietary storage).

This also works seamlessly for all other applications that use SSH, such as git, rsync, scp, etc.

Note that there's also a standard program ssh-agent which is the most commonly used ssh agent implementation. It is typically used like so:

ssh-agent  # this start the agent
ssh-add path/to/private-key   # this adds a key to currently running agent
ssh my-host  # the key is provided automatically

what is the difference to a keyring (which I also never used) to an ssh-agent?

I'm not an expert here, but my understanding is that the keyrings are the programs provided OSes or desktop environments, which are used as secure storage for applications (and users) to store their secrets. This is similar to what password manages do, but keyrings are mostly used by other applications. For example, a browser may use the system keyring to store the saved passwords. A keyting program could potentially be used to store private keys and to act as an SSH agent, but I'm not aware of any keyring app that actually implements that.

[buhtz]

Thank you for explaining this. It is clearer now for me.

So what would be the job for BIT in this use case? Simply not using any key-file options, if I understand this correct. In this case it is easy to implement, of course. 😄

[andreyfedoseev]

So what would be the job for BIT in this use case? Simply not using any key-file options, if I understand this correct.

Yes, exactly. Just let the user to leave the private key file blank. Note that the user can also configure the private keys per host in their .ssh/config file. In such case, using the -i path/to/key option for ssh is also unnecessary, because the relevant key will be used automatically, even without using an SSH agent.

You can probably display a warning to the user when they leave the private key field blank, saying that it is their responsibility to specify a valid key via .ssh/config or otherwise (e.g., via an ssh agent).

In general, if ssh my-host works without using password auth, and without using the -i option, then it's ok to leave the private key blank in BIT.

[buhtz]

Thank you. Now the next steps are clear. So this feature will be implemented and it is clear how to do it.

[andreyfedoseev]

Thank you, looking forward to it!

[buhtz]

Free from your guts. Which mock up do you prefer. The one with all options in one drop down or the the one with two radio buttons?

Mock A - All options in one drop down

Mock B - Two radio buttons

[andreyfedoseev]

Which mock up do you prefer. The one with all options in one drop down or the the one with two radio buttons?

I like the second one better: Mock B

[sevens]

For some extra context: I have regular ssh-agent set up with ksshaskpass (so the passswords for the SSH keys are stored in kwallet) and automatically ssh-add all the keys into the agent when KDE starts up; so after login I can ssh HOST into any host that has the keys setup without providing a password for the key, like described above.

If there's ssh-agent-specific info needed let me know, though AFAIK there should be no difference to other agent implementations as far as BiT is concerned.

[buhtz]

Use system SSH configuration

Tooltip: Leaves the key file unselected. SSH connections will rely on the system’s existing client configuration (e.g., ~/.ssh/config).

[buhtz]

Would be glad if someone could take a look at PR #2197, review the code and test the feature.

I have not yet finished the GUI elements for this feature. This will happen in a follow-up PR (#2196). To disable using a SSH-key the key-file field in the Manage profiles dialog need to have the value False.

[buhtz]

OK, now I also can present a new widget capable of selected and generating SSH keys. Please take a look in the PR #2196 including the screencasted widget. Let me know what you think. Don't hesitate to suggest modifications.