backintime
backintime copied to clipboard
bit-team
Back in Time 1.3.3 (on a Raspberry PI running Bookworm) fails to recognize host key it added to known_hosts
After restoring settings from a remote profile, Back in Time 1.3.3 (on a Raspberry PI4 running Bookworm) complained of failing authentication (ECDSA) and asked to add the key to known_hosts. The key could be seen to have been added, but Back In Time didn't recognize it and kept asking to be allowed to add the key.
By accident I manually added the key using ssh-keygen without -H, so the address at the start wasn't hashed.
Surprise: Back in Time settings were happy.
(I removed the numerous keys for the host computer added by back in time before the manual addition.)
Before installing Bookworm on this machine, it had ran BackInTime just fine, but that must have been a different version. My other PI's run BackInTime 1.2.1 and 1.1.24 and I can't remember having the key recognition problem with those. They run an older OS, like Buster or Bullseye. My desktop NUC also runs 1.3.3, but that is on LMDE 6. It also doesn't have this problem.
To help us diagnose the problem quickly, please provide the output of the console command backintime --diagnostics.
pi@RPI-HUB:~ $ backintime --diagnostics
{
"backintime": {
"name": "Back In Time",
"version": "1.3.3",
"latest-config-version": 6,
"local-config-file": "/home/UsernameReplaced/.config/backintime/config",
"local-config-file-found": true,
"global-config-file": "/etc/backintime/config",
"global-config-file-found": false,
"started-from": "/usr/share/backintime/common",
"running-as-root": false,
"user-callback": "/home/UsernameReplaced/.config/backintime/user-callback",
"keyring-supported": false
},
"host-setup": {
"platform": "Linux-6.6.28+rpt-rpi-v8-aarch64-with-glibc2.36",
"system": "Linux #1 SMP PREEMPT Debian 1:6.6.28-1+rpt1 (2024-04-22)",
"os-release": {
"NAME": "Debian GNU/Linux",
"ID": "debian",
"PRETTY_NAME": "Debian GNU/Linux 12 (bookworm)",
"VERSION_ID": "12",
"VERSION": "12 (bookworm)",
"VERSION_CODENAME": "bookworm",
"HOME_URL": "https://www.debian.org/",
"SUPPORT_URL": "https://www.debian.org/support",
"BUG_REPORT_URL": "https://bugs.debian.org/"
},
"display-system": "wayland",
"locale": "nl_NL, UTF-8",
"PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games",
"RSYNC_OLD_ARGS": "(not set)",
"RSYNC_PROTECT_ARGS": "(not set)"
},
"python-setup": {
"python": "3.11.2 main Mar 13 2023 12:18:29 CPython GCC 12.2.0",
"python-executable": "/usr/bin/python3",
"python-executable-symlink": true,
"python-executable-resolved": "/usr/bin/python3.11",
"sys.path": [
"/usr/share/backintime/qt/plugins",
"/usr/share/backintime/common/plugins",
"/usr/share/backintime/plugins",
"/usr/share/backintime/common",
"/usr/lib/python311.zip",
"/usr/lib/python3.11",
"/usr/lib/python3.11/lib-dynload",
"/usr/local/lib/python3.11/dist-packages",
"/usr/lib/python3/dist-packages",
"/usr/lib/python3.11/dist-packages"
],
"qt": "PyQt 5.15.9 / Qt 5.15.8"
},
"external-programs": {
"rsync": {
"program": "rsync",
"version": "3.2.7",
"protocol": "31.0",
"copyright": "(C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others.",
"url": "https://rsync.samba.org/",
"capabilities": {
"file_bits": 64,
"inum_bits": 64,
"timestamp_bits": 64,
"long_int_bits": 64,
"socketpairs": true,
"symlinks": true,
"symtimes": true,
"hardlinks": true,
"hardlink_specials": true,
"hardlink_symlinks": true,
"IPv6": true,
"atimes": true,
"batchfiles": true,
"inplace": true,
"append": true,
"ACLs": true,
"xattrs": true,
"secluded_args": "optional",
"iconv": true,
"prealloc": true,
"stop_at": true,
"crtimes": false
},
"optimizations": {
"SIMD_roll": false,
"asm_roll": false,
"openssl_crypto": true,
"asm_MD5": false
},
"checksum_list": [
"xxh128",
"xxh3",
"xxh64",
"md5",
"md4",
"sha1",
"none"
],
"compress_list": [
"zstd",
"lz4",
"zlibx",
"zlib",
"none"
],
"daemon_auth_list": [
"sha512",
"sha256",
"sha1",
"md5",
"md4"
],
"license": "GPLv3",
"caveat": "rsync comes with ABSOLUTELY NO WARRANTY"
},
"ssh": "OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023",
"sshfs": "3.7.3",
"encfs": "(no encfs)",
"shell": "/bin/bash",
"shell-version": "GNU bash, versie 5.2.15(1)-release (aarch64-unknown-linux-gnu)"
}
}
Additionally, please specify as precisely as you can the package or installation source where you got Back In Time from. Sometimes there are multiple alternatives, like in for Arch-based distros.
Installed from Raspberry Pi package repository using the GUI function Add/remove programs.
As an alternative fell free to use our mailing list for every topic about Back In Time. Visit the subscribtion page at https://mail.python.org/mailman3/lists/bit-dev.python.org or send an email with subject "Subscribe" to [email protected].
Hello Arjen,
Thank you for taking the time to report the issue and providing the details. We appreciate your feedback.
It may take some time. Myself I don't understand all details of your problem and need to setup a VM doing some tests. But I am in the middle of reinstalling my whole system. My team mates or also offline for some days.
If you have any more details to share, feel free to reach out.
Best regards, Christian
By accident I manually added the key using ssh-keygen without -H, so the address at the start wasn't hashed.
Surprise: Back in Time settings were happy.
But isn't that the expected behavior and an explanation of your problem?
Do you still see a bug? Please let me know and explain in more details. I do not get it, yet what the bug is and how BIT can improve its behavior.
Hello Arjen, it would help us a lot if you could report back. In the current state of information I don't understand the problem and I am also not able to reproduce it. Please add more details or add detailed steps to reproduce it. In the latter case I can setup a VM to investigate the problem.
Otherwise I need to close Issue.
Best regards,
Hi, I am sorry my explanation is still not detailed enough. If my wording is unclear I will try to explain what I mean to say, but I cannot now investigate the problem again.
I just did a small test. On the pi running bookworm 64 bit and BiT 1.3.3. In the BiT settings I changed one or two letters in the host name to capitals. This caused an error message on pressing OK. The error message mentions the ecdsa fingerprint, but I use ED25519 for the private key as you can see. With all lower case host computer name, there is no problem. The actual host computer is a Netgear NAS RN212. I think it is part of the problem not fully supporting ECDSA keys. The port used - not shown - is forwarded in the router to the actual NAS. The host computer name is the dynamic domain name of my XR500 router with recent build of DD-wrt firmware. I cancelled the error message and changed the capitals to lower case again. I can’t risk more trouble now. I can send a screen dump of the error message from my workstation once I find where to send it and exclude possible security risks. I made the screen dump and will try to send it to you.
I hope it helps.
Thank you for reporting back. The error you describe now sound different from the one you described in your initial post. I am getting more confused. 😄
Don't risk your productive system. But if even you are not able to know about the steps to reproduce I am also not able to reproduce.
You might setup an virtual machine and try to reproduce it there?
In the end SSH is a very simple thing. If you can login into your SSH server on shell via $ ssh user@server without being asked for a password, because a key is setup, then it should go well with BIT, too.
You also have not yet provided debug output. Start BIT with --debug option. You might find something relevant in the debug output in terminal.
Closing this ticket based on the comment above. Feel free to reopen if the problem still exists. Thank you for your efforts. If you have any further questions, ideas or encounter any other issues, please don't hesitate to let us know.
Best regards,