Back In Time

Backintime as root with ssh / key based login w/o passward

Asked by Kai Dupke

Hi,

thank you for this great tool! I'm used to use backintime with ssh and key based authorization, with no password set on the key.

This does work still for a non-root account, but for a root account it does not work as the setup tries to save the password.

However, with an empty password there is no need to save, nor to cache etc. a password.

What I would recommend is to add a check-box 'key with no password' or just don't try to save when the password string is empty.

The reason I set up systems this way and not as a user account is that at the moment I set up the system there is no other user then root, the owner of the system set up his own account.

Having backintime backing up /home it will automatically catch the user account plus is able to save /etc, /boot, /var/log - which enables me to help in case something happens.

Any ideas how to get this running as root the described way? Or do I have to change the code?

greetings kai

Question information

Language:
English Edit question
Status:
Solved
For:
Back In Time Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Kai Dupke (c-launchpad-5) said : 		#1

Looks like hitting saving triggers this, as it tries to mount with the data and the mount then tries to access the keyring.

However, this does not change the idea, to not use the keyring when the key does not need a password, right?

Still digging, first time I read Phyton code, sorry!

greetings kai

Revision history for this message
Kai Dupke (c-launchpad-5) said : 		#2

Me again, if I comment out line 89 in sshtools.py "self.unlock_ssh_agent()" then it works for root.

Thinking about it, might be better to have a check box 'don't use ssh-agent' instead of just checking for a blank password.

The lines below works for me, but I'm not sure how to propose this change and if there are side effects I'm not aware.

diff */*/sshtools.py
89,92c89,90
< # ssh without password makes only sense if you have enabled passwordless ssh keys. In this case there is no need to use the keyring at all
< if not self.password == None:
< self.unlock_ssh_agent()
<
---
> self.unlock_ssh_agent()
>

Revision history for this message
Germar (germar) said : 		#3

I just double checked and can't confirm your problems. I created a passphrase-less key, added a new profile in BIT and left password empty, 'Save Password to Keyring' disabled and 'Cache Password for Cron [...]' enabled.

Which version do you use? Can you please run 'gksu backintime-gnome' from terminal and post the output after your problem happened again?

Revision history for this message
Kai Dupke (c-launchpad-5) said : 		#4

Thanks for picking this up.

This is backintime 1.0.34, I run it with KDE.

Using the original code I get an error even starting backintime-kde (running it with the patch above works well, so I assume the 'wrong' settings are saved: "Could not unlock ssh private key. Wrong password or password not available for cron."

Don't have gksu on my system. What I do is, login as ordinary user, the start an xterm and use "su -" to become root.

With backintime-gnome it works out of the box.

Looks like this is a problem with the KDE version only.

Just double checked. Fresh install of backintime, -gnome is working, -kde isn't working.

greetings kai

Revision history for this message
Germar (germar) said : 		#5

Ah, okay. I only tested on Ubuntu 13.10 with backintime-gnome. But I was now able to reproduce the error on Kubuntu 13.10 with backintime-kde4 1.0.34
Will have a look on this soon.

Don't worry about gksu. This is only for Gnome based Desktops. You can use 'kdesudo -c backintime-kde4' or 'kdesu [...]' from terminal

Revision history for this message
Launchpad Janitor (janitor) said : 		#6

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Kai Dupke (c-launchpad-5) said : 		#7

OK, so what is the next step? Having this expired does not solve the issue, right?

Revision history for this message
Germar (germar) said : 		#8

I didn't find the time to trace this down, yet. I'll change this into a bug report and close the question again.

Revision history for this message
Germar (germar) said : 		#9

closed