Restic refused to backup my private key and I did not know

I am using restic to backup ~2TB to wasabi. It works great. I usually do random checks. And today I realised that restic was not backing up my private key in .ssh directory but actually was backing up the rest of the files in it.

The obvious thing to look at is the permission of the files in that directory. My user account has sudo privilages and even without sudo privilages, I can view my private key. This is the key that was never backed up. And I did not even a see an error in the restic err log saying that there was a difficulty reading or backing up this file. This would have been a serious problem had I not detected this. So, I want to get to the bottom of this and understand the reason for this behavior.

The file permissions on my local PC are listed below. Restic backup is completed by a cronjob. Daily.

Specifically, id_rsa was skipped, id_rsa_pub was skipped too. With no logs of erros for either of them.
The rest of files in this directory were well backed up over the years.

UPDATE:

Restic was indeed backing that private key, but into a different folder that is different from the original folder structure on my original PC. So, why would Restic chose to create a different folder inside .ssh dir? The private keys have gone inside .sshO dir. I do not recall creating this dir and it is present in the latest repository. But in my PC, the directory “.ssh/.sshO” does not exist.

UPDATE SOLVED

This is weird. By simply adding ‘/’ to the backup directory path, suddenly the .ssh dir is backed up correctly as I would have expected.

Below is my list of directory list.
image

This behavior is new to me. Can anyone explain why this happens?

As a first step I think it would be useful if you could post the whole command, how you call restic to do your backup.

Hi, please find the following:

And the resticfiles txt file is below. Earlier this file did not contain a ‘/’ at the end. Basically, its just a bunch of file paths. :slight_smile:

image

It’s a bit hard to follow the screenshots you provide when you censor so much of them, e.g. I’m not sure what to make of the last image as there’s no way of knowing what’s hidden before the top-most /. That file would be good to see in its entirety (at least the part that could in any way be related to or reference the ssh-related stuff).

But anyway, can you do the backup run with -vv (two v’s) as options, filter the output and show us the lines that include ssh in them? I’m just curious what ssh-related paths restic backs up. Please do it both without and with the / that you found was making a difference.

Also, perhaps it would be better if instead of covering screenshots, you just copy the text, replace your username and similarly sensitive things with some dummy text of the same type (e.g. lsuru with bob or whatever) and pasted that. It makes it easier to follow.

Which restic version are you using? Are the backup paths absolute or relative paths?

The backup paths are absolute paths. e.g,

/home/username/folder1
/home/username/.config/
/home/username/.ssh/

And I believe myrestic command is clear despite i have blurred some parts of it which are obvious like file names. Eitherway, my question is very specific.

Should restic change its behavior if there is a / at the end of the restic backup path? If this your behavior? Im happy with how restic works. Im not sure if this is a bug. But I felt its important the devs know that a / makes a difference. I am sure of it. Im on Arch.

restic 0.12.1 compiled with go1.16.6 on linux/amd64

1 Like

I don’t understand how that could be possible. restic uses the golang filepath.Clean method to cleanup all file paths before any further processing, which removes the trailing /. What does restic ls <snapshotid> /home/username/.ssh/ print for some of the affected snapshots?

Please do the above as well as what @MichaelEischer asked.

FWIW, I just tried this on a local machine I have here (macOS 10.14.6). The result is that I cannot reproduce it - it doesn’t matter if I ask restic to back up /Users/username/.ssh or /Users/username/.ssh/ - the relevant output from -vv for the two backup runs and ls for the two snapshots is the same (see below). I also tried the exact same thing but using --files-from instead of listing the path directly on the command line, and the result is the same - I cannot reproduce this with latest restic 0.12.1 and macOS 10.14.6.

$ ./restic -r bepa backup -vvv /Users/username/.ssh
open repository
repository cca27d80 opened successfully, password is correct
lock repository
load index files
no parent snapshot found, will read all files
start scan on [/Users/username/.ssh]
start backup on [/Users/username/.ssh]
scan finished in 0.256s: 12 files, 25.016 KiB
new       /Users/username/.ssh/config, saved in 0.002s (235 B added)
new       /Users/username/.ssh/id_rsa, saved in 0.003s (1.702 KiB added)
<snip>
new       /Users/username/.ssh/id_rsa.pub, saved in 0.001s (401 B added)
new       /Users/username/.ssh/known_hosts, saved in 0.001s (14.275 KiB added)
new       /Users/username/.ssh/, saved in 0.012s (0 B added, 4.194 KiB metadata)
new       /Users/username/, saved in 0.012s (0 B added, 376 B metadata)
new       /Users/, saved in 0.013s (0 B added, 378 B metadata)

Files:          12 new,     0 changed,     0 unmodified
Dirs:            3 new,     0 changed,     0 unmodified
Data Blobs:     12 new
Tree Blobs:      4 new
Added to the repo: 30.311 KiB

processed 12 files, 25.016 KiB in 0:00
snapshot 6bc325fd saved


$ ./restic -r bepa backup -vvv /Users/username/.ssh/
open repository
repository cca27d80 opened successfully, password is correct
lock repository
load index files
using parent snapshot 6bc325fd
start scan on [/Users/username/.ssh/]
start backup on [/Users/username/.ssh/]
scan finished in 0.232s: 12 files, 25.016 KiB
unchanged /Users/username/.ssh/config
unchanged /Users/username/.ssh/id_rsa
<snip>
unchanged /Users/username/.ssh/id_rsa.pub
unchanged /Users/username/.ssh/known_hosts
unchanged /Users/username/.ssh/
unchanged /Users/username/
unchanged /Users/

Files:           0 new,     0 changed,    12 unmodified
Dirs:            0 new,     0 changed,     3 unmodified
Data Blobs:      0 new
Tree Blobs:      0 new
Added to the repo: 0 B  

processed 12 files, 25.016 KiB in 0:00
snapshot 0218a677 saved


$ ./restic -r bepa snapshots
repository cca27d80 opened successfully, password is correct
ID        Time                 Host            Tags        Paths
------------------------------------------------------------------------------------------------------------
6bc325fd  2021-10-24 14:05:01  vistonia.local              /Users/username/.ssh
0218a677  2021-10-24 14:05:10  vistonia.local              /Users/username/.ssh
------------------------------------------------------------------------------------------------------------
2 snapshots


$ ./restic -r bepa ls 6bc325fd
repository cca27d80 opened successfully, password is correct
snapshot 6bc325fd of [/Users/username/.ssh] filtered by [] at 2021-10-24 14:05:01.199799 +0200 CEST):
/Users
/Users/username
/Users/username/.ssh
/Users/username/.ssh/config
/Users/username/.ssh/id_rsa
<snip>
/Users/username/.ssh/id_rsa.pub
/Users/username/.ssh/known_hosts


$ ./restic -r bepa ls latest
repository cca27d80 opened successfully, password is correct
snapshot 0218a677 of [/Users/username/.ssh] filtered by [] at 2021-10-24 14:05:10.142887 +0200 CEST):
/Users
/Users/username
/Users/username/.ssh
/Users/username/.ssh/config
/Users/username/.ssh/id_rsa
<snip>
/Users/username/.ssh/id_rsa.pub
/Users/username/.ssh/known_hosts

Hmm, not sure if this may be relevant, but the two screenshots you provide (the content of your local .ssh folder and the content of the remotely backed up .ssh folder) don’t seem to match anyway. The dates and files sizes are different, so whatever is backed up remotely might be from another machine where the .sshO folder does exist?

1 Like