Rsync Crypt
You set up an rsync crypt workflow by pairing secure transport with local disk encryption. The standard rsync tool moves files over SSH, while a separate tool encrypts files at rest. Engineering teams often use this setup to back up servers or sync sensitive folders across hosts. Still, teams often grant broad SSH keys and root roles to make automated sync jobs work. When permissions are too wide, any person or script with that key can run bad commands. How an rsync crypt workflow operates in
Crypt: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an rsync crypt workflow by pairing secure transport with local disk encryption. The standard rsync tool moves files over SSH, while a separate tool encrypts files at rest. Engineering teams often use this setup to back up servers or sync sensitive folders across hosts. Still, teams often grant broad SSH keys and root roles to make automated sync jobs work. When permissions are too wide, any person or script with that key can run bad commands.
How an rsync crypt workflow operates in practice
The native rsync tool does not encrypt stored files on its own. Instead, it relies on an SSH tunnel to protect data while it moves across the network. Once the files arrive on the remote server, they sit on the disk in plain text. To get true encryption at rest, teams add a storage encryption tool before or after transfer.
In a pre-transfer setup, the team mounts an encrypted virtual folder on the source machine. The local tool encrypts every file name and file block before the sync job starts. Next, rsync reads those scrambled files and sends them over SSH to the remote backup host. The remote host only stores the scrambled data and never holds the decryption key.
In a post-transfer setup, the destination server uses full disk encryption or an encrypted folder. The sync job sends plain files over the encrypted SSH tunnel into that mounted target folder. When the folder unmounts, the underlying blocks remain locked on the storage drive. Both methods require user accounts and SSH keys on the source and target hosts.
What native file sync solves and what it leaves open
Combining SSH transport with disk encryption solves two major security problems for operations teams. Network attackers cannot read files in flight, and stolen hard drives do not leak raw data. If someone pulls a backup drive from a data center, they only get unreadable ciphertext. This approach works well for offsite backups and cloud storage sync jobs.
Yet this native setup only checks who can log in to the host machine. It does not check or restrict what individual commands do once the SSH session starts. To let rsync read and write system files, admins often assign broad shell roles. A user or automated script holding that SSH key can log in and run anything.
Crypt: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static SSH keys also sit on laptops and build servers for months without rotation. If an attacker steals a sync key, they can delete backups or pull sensitive production data. Native host logs only show that an SSH login happened, not the exact commands run. Teams also lack a way to require peer approval before a risky sync job runs. Data masking is absent too, so plain transfers can copy emails, phone numbers, or card numbers.
Managing host roles and command checks for file transfers
To reduce risk, teams try to lock down the SSH key on the target server. Admins can configure the host to only allow a single sync command for that specific key. Still, maintaining those manual host rules across dozens of servers takes a lot of time. When a folder path changes, an engineer must update the rule file on every host.
Shared service accounts create another blind spot during security audits. When five engineers share one backup key, the server log shows the same user name. You cannot tell which team member ran a manual sync or changed a remote file. Security teams need individual user identity tied to every single action on the host.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does rsync encrypt files by default?
Modern rsync uses SSH as its default transport, which encrypts data while it moves over networks. It does not encrypt files on the destination disk unless you use a separate encryption tool.
How can we encrypt files before syncing them to a remote server?
You can use a file-based encryption tool to create an encrypted folder on your local disk. Then you run your sync job on the ciphertext folder so the remote host stores scrambled files.
Why are static SSH keys risky for automated sync jobs?
Static keys rarely expire and often hold broad read and write permissions on the target server. Anyone who copies the key file can log in to the host without approval or oversight.