Time Machine Security vs Automated Script ssh key Security

Hi Bob,

Thanks again for the info on the key chain. I've been digging around quite a bit since my last post. I found this article which I think answers most of my questions about the keychain and time machine.

Keychain data protection - Apple Support

There are different classes of key access including: "while unlocked" or "after first unlock", the latter being the one that would be interesting for a background backup script. There are a number of keychains (System, local, login) that are visible in the Key Assistent. I was able to locate my Time Machine key and it is in the system key chain - but I can't see how to show the access value. It behaves as if it has at least the 'after first unlock' class since it can run while the system is sleeping. I haven't tried to figure out if it will run after a reboot before the first unlock.

I also bumped into a couple of other reference that stated that add-ssh to macOS keychain seems to work OK for background jobs while the system is sleeping. I haven't determined what keychain ssh-add uses or what access class it gets. I'm about to give that a test to verify it works,. So I think my resultant plan will be to use the keychain to store the phasephrase for the ssh key.

A few other things I ran into:

• On monterey, ssh-add switches -A and -K are deprecated and replaced by --apple-load-keychain and --apple-use-keychain
• On my synology, even if you are using ssh keys for access, the ability to ssh via password authentication remains enabled unless you turn it off (e.g. /etc/ssh/sshd_config : PasswordAuthentication no). I'm not going to do that because I'm afraid I'll get locked out or maybe affect something else. If you leave it enabled, you still need to make sure you have strong passwords and maybe set up auto block users on to many failed password attempts to avoid a brute force attack.

So first, as part of disclosure, this is my first Mac, my first NAS, but I do have some crypto experience. Yes, the NAS doesn't need the private key, just the public one. And yes I have a screen saver password. And by the way my NAS is Synology. You mentioned File Vault - thanks for that - I was not aware of it before - and I have not turned it on yet (and I don't think I will). But I think (at first glance) that would address most of the security issues I'm going to mention below.

If you are running time machine (for example), it backs up the entire internal hard-drive (minus your explicit exclusions and whatever default exclusions it has). But for recovery, it would need to include the Users directory and specifically your ~/.shr directory which has your public and private keys in it and additionally your key chain which is encrypted with your login password. The NAS doesn't need it, but you do for recovery from an internal hard disk failure. I did look at the key chain access app but I'm not sure I understand what it is telling me - I'm not sure I found the entry for Time Machine or would understand the info. if I did I'm still a bit uneducated about the key management here but I have the following working model in mind:

• Key chain is encrypted with a secure hash of the user login password. Only accessible while the user is logged in.
• Passwords and pass phrases that are stored in the key chain are protected by the key chain encryption.
• Private keys generated by ssh key gen that have a pass phrase are encrypted by a secure hash of the pass phrase. If the pass phrase is in the key chain, the key is secured by the pass phrase, that is secured by the key chain encryption.
• Private keys that are generated by ssh key gen that do not have a pass phrase are in the clear in the .ssh directory.
• Passwords or pass phrases that are stored by some program (Time Machine?) that are not stored in the key chain are in the clear somewhere on the machine.
• Data on the NAS can be protected by encryption. Either by encrypting at the NAS, if supported by the NAS, or by the system, before it is sent to the NAS.

And yes, is someone has the password for a NAS user with access to the Time Machine directory or the private key for any ssh public keys authorized on the NAS for a user with access to the Time machine directory, then that person has access to the NAS time machine folder which contains Time machine backups from EVERY system using that NAS. Same goes for whatever folder you might use for something like rsync. If the data is not encrypted and there are private keys in the clear in the data, then whatever those keys protect is at risk.

I didn't explain why I'm using rsync for, but basically, because of a lot of reports online of problems with Time Machine recovery, I wanted to try setup a secondary backup mechanism which was not based on Time Machine. More specifically, I was going to use the latest system snapshot and rsync it (the entire internal disk) to the NAS. So again, now the ~/.ssh directory is on the NAS (twice). The NAS doesn't need it but to recover from a hard drive failure when the Time Machine backup is corrupted, I need the private keys and the key chain in the backup.

I agree that ssh keys without a pass phrase is "relatively safe" - someone would have to hack into your system or NAS to get the private key - like "guess" your password or find it written down somewhere it shouldn't be. But it's not "secure" from a cryptographic standpoint. File Vault would cover this exposure though, assuming your protect your File Vault and login credentials.

At least for the moment, still feel I have to choose between (1) an automated backup script with a private key in the clear on the host or (2) only running the script manually while I'm logged in - which protects the private key on the system disk. To protect the NAS, I'd have to enable encryption on the rsync folder. And this might not be worth it if the Time Machine data is not encrypted - though it seems to be more obfuscated than an rsync copy would be.

I'm still not sure I understand how Time Machine is running when the user is logged out and how secure the remote credentials are in this case.

Yes - that is my case 4 in the original post. My understanding is that an automated script would not work when the user is not logged in because the key chain is locked.