Give OPNsense SFTP backups a separate key and retention decision

Bottom line: Give the firewall backup job its own access purpose and recovery requirement. A successful connection test should lead to inspection of the retained backup and the authorized recovery path, rather than becoming the entire backup acceptance record.

Source fact: what the authority says

The OPNsense SFTP backup guide requires installation of the os-sftp-backup plugin. Its preparation distinguishes the private key from the public key offered to the backup host and recommends a separate key for the backup. The plugin settings include the target URL, uploaded SSH private key, number of backups to keep and an optional backup-encryption password. The documented Setup/Test sftp control checks the configuration and reports a connection failure.

What the source does not establish

The cited setup procedure does not establish that a retained file can recover the intended firewall state. This article does not prescribe a universal target retention or permission model. DSE treats target access, backup content, recovery prerequisites and restoration evidence as separate review subjects.

Applicability questions

• Which target account, directory and firewall are authorized for this backup purpose?
• Where is the dedicated private key held, and who can retrieve or replace it?
• How many generations must survive, and who approves any optional encryption-password decision?
• Who can retrieve a selected generation and perform a controlled recovery exercise?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends assigning a dedicated key to the approved firewall-to-target relationship. Record its public identifier, target account, purpose and owner without copying private material into the change record. Have the target administrator review the allowed destination and operations against the backup requirement. Keep unrelated interactive access out of the proposed key’s purpose.

Translate the recovery requirement into a deliberate generation count before saving the plugin settings. Decide how an encryption password, if selected, will be available to authorized recovery personnel without appearing in routine job evidence. Record the protected retrieval method and responsible owner. Avoid making the newest visible filename the only answer to which recovery point the organization intends to keep.

Use the documented connection test as one checkpoint. Then choose a retained backup generation for inspection and an approved recovery rehearsal. For a proposed rotation exercise, replace only the dedicated test key and assess whether the backup workflow can be restored without sharing another service’s credentials. Keep any revocation or production rotation outside the rehearsal unless separately authorized.

For the retention review, compare two successive approved backup cycles and identify the generation selected for recovery after each. Keep the actual observed history rather than assuming the configured count proves every intended generation is present and readable.

Verification and evidence

Proposed verification: observe an approved backup cycle and identify the resulting generation at the intended target. Compare the actual target, timestamp and retained generation set with the saved configuration. Retrieve a selected copy through the authorized recovery route and assess its content without exposing configuration secrets in a shared report.

In an isolated or approved representative recovery arrangement, follow the applicable official restoration procedure and record the actual outcome. Keep connection-test evidence separate from retrieval and restoration results. Include a controlled failed-connectivity case where permitted, and confirm that the assigned operator can identify the failure and its investigation path. Retain configuration identifiers, public-key identifiers and redacted observations.

Official references

• OPNsense — Backups via secure copy (sftp) — official product documentation; confirm the installed release and configuration.

Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.