I never said that and I’m not even sure what you mean by executing restic: snapshots on the remote server.
My point is that instead of trusting the information you get from a client which may be compromised, you are better off trusting the information from the server directly, by inspecting the snapshot files in the actual repository on the server, instead of relying on some cron output from your client.
I’m talking about “restic -r /srv/restic-repo snapshots”.
I’m calling this from a cron and post-processing the commands output, sending it by email.
A couple of thoughts regarding “may be compromised”:
Ensuring and monitoring if a client is compromised or not is not within the scope of monitoring if a backup has been executed. I would keep these two tasks seperated.
If I can’t trust the client, I can’t trust anything happening on the client and then I also can’t trust the server as the client has access to the server. Then monitoring restic/backup is the least of my problems
If you by default don’t trust clients, how then do you get reliable information from a server? As why wouldn’t you trust a cron on a machine A calling restic :snapshots over sftp with key based auth on a remote server but you would trust a i.e. a sftp connection to the server from a machine B, listing the remote snapshots dir? I really don’t see the difference there?
Maybe you could lay out what attack vector you see that would make a difference?
We seem to be talking about different things here, and frankly I have better things to do than to elaborate more on this than I already have. If you think I have been unclear, then sorry about that.
I’m not saying that inspecting the snapshots/ files on the server is a fool-proof way of determining whether backups run properly or not. In reality it’s far from that. It’s just an indication, but my point is that it’s a better indication than some output from a cron script, IMO.
If I understood correctly, @rawtaz reasons like this:
Machine A is a random client machine which is making backups. It is not trusted.
Machine B is an “admin machine” which is (to a higher degree) trusted.
This means that an attacker is thought to have a better chance of controlling machine A. One of the attackers goals might be to fool you into thinking that backups have been performed, when, in fact, they have not. The attacker is hoping that you are 1) monitoring the supposed state of machine A, 2) NOT monitoring the repository from a trusted machine and 3) you run restic forget to remove old backups. This way he reaches his goal of making sure that all copies of your valuable data is lost before you realize you were under attack.
Hope I made things clearer. And that I did not “misrepresent” @rawtaz .
We seem to be talking about different things here, and frankly I have better things to do than to elaborate more on this than I already have.
Understand. Same here regarding trying to understand what you mean - i could have ignored your comment but since you took your time to provide input, i thought ignoring it instead of asking for clarification might be disrespectful.