Just to test, yesterday I ran
sudo chmod 0664 /home/user-content/backup/encrypted/*
and this morning the incremental backups are all 0644, so I do indeed have an “undocumented” change, it appears, since everyone else is 0600 on those files. Wish I could figure out what I changed, because my backup method seems easier than what everyone else is doing.
No, because you can see setgid/setuid in the normal directory permission because the x is replaced with s:
username@servername:~$ ll normaldirectory/
drwxrwxr-x 6 username groupname 4.0K Nov 23 2018 normaldirectory/
username@servername:~$ ll setgiddirectory/
drwxrwsr-x 6 username groupname 4.0K Nov 23 2018 setgiddirectory/
Yes that would be the way to do it.
My VPS is set up to only accept ssh login with SHH key, no password.
user-data as no password set up, and no ssh key.
I will stick with
rsync -avz -e “ssh” --rsync-path=“sudo rsync” box.hostname.xx:/home/user-data/backup/encrypted /data/backup/MailInabox/.
as it works well. (it jsut took me some time to find it 
)
I have use no password but have installed the SSH key for authentication.
I am not sure what security issues may arise with your method, if any.
Anything on this at all?
You just need to copy secret_key once, no? Or do you mean the security issues with being able to rsync the secret_key.txt as well?
Shouldn’t the system that is performing the rsync being also a secured medium that you are in control?
This may or may not be applicable, I haven’t thought through how the rsync command would need to be started, but you could also look in to using “ssh forced commands”.
Basically, you change sshd_config to include PermitRootLogin forced-commands-only. Then in the /root/.ssh/authorized_keys file you can include a line like:
command="/usr/bin/rsync" ssh-rsa …
Those restrict root login to only executing whatever commands you define in the authorized_keys file and you can then use different keys to trigger different commands.
I’m using duplicacy to backup to my home NAS and I use two keys to trigger different backup tasks. The NAS connects and creates a reverse tunnel that the forced command then uses to send the backup data. This was my solution for getting the backup data to the NAS without having to keep a port open at all times and leave NAS credentials on the MIAB machine.
If desired, you could use from="<IP>",command=... to only allow access from a given list of IP addresses.
If the root user can run rsync, then the command rsync / can be run to gain a copy of the entire installation.
I would not consider this as “good operating practice” when it comes to automated remote backups.
Again, somehow I have already implemented a much more secure and better solution of changing the encrypted file permissions to 0644, and eventually I will discover how I did this and post.
You are all free to do with your server as you choose, but I strongly advise against it.
644 means anybody can read isn’t it? It’s own by user-data isn’t it?
@Alento’s solution work quite well without exposing your files through 644.
That is correct. Anyone can read the encrypted files. Decrypting them is another matter.
If the encryption is broken, you have other things to worry about.
hello, copying backup files was not a problem albeit, regarding accessing secret_key, i was manage to make it by:
sudo cp --no-preserve=mode /{path}/secret_key.txt key_copy.txt
with a regular (sudoer) user! Once is enough, it doesn’t change i think, just keep it somewhere safe. br.