Secure SFTP Backups with SSH Keys: A Practical Playbook

If your backups depend on a shared password and someone remembers to click a button, you don’t have backups - you have a wish. SFTP with SSH private keys is the boring, durable approach to push or pull data offsite on a schedule, without babysitting, that passes audits and keeps costs sane. Here’s the operator’s playbook: what to decide, how to build it, and how to keep it trustworthy when people change, vendors churn, and quarters get busy.

Passwords fail operationally. They expire, get pasted into the wrong places, and end up in Slack. Private keys remove that whole class of risk. You provision a keypair per system, restrict it to a narrow command and directory, and your jobs run unattended. No one is rotating a password the morning of your board meeting.

Compliance teams also sleep better. SOC 2, ISO 27001, HIPAA, and local data-protection regimes all ask versions of the same question: can you prove your data is backed up, encrypted in transit, access-controlled, and restorable? Key-based SFTP answers the first three in one shot and makes the fourth (restore tests) easy to automate.

Finally, cost. You don’t need to overpay for another glossy “backup platform” if your needs are straightforward: get data out of production, encrypt, ship, retain, and test restores. SFTP to a hardened dropbox with key auth is cheap, understandable, and predictable. Spend the saved budget on things that move revenue.

At the core are two files: a private key you keep secret on the machine that initiates the backup, and a public key you share with the SFTP server. The server uses the public key to verify a challenge response from the private key. If it matches, you’re in - no passwords sent over the wire.

You can add a passphrase to the private key. That protects the file if someone steals the disk, but it complicates automation unless you use an agent or a secrets manager to provide the passphrase non-interactively. Decide based on your threat model and compliance obligations. For many servers, a passphrase plus a machine-bound secrets store is the right balance.

Not all keys are equal. Ed25519 keys are small, fast, and secure for new setups. RSA 4096 is common and widely supported if you’re stuck with legacy. Avoid DSA. Make sure both sides agree on supported key algorithms and ciphers to avoid 2 a.m. “couldn’t agree on key exchange” failures.

Public/private key basics (without the mystique)

When you run a key generator, it creates two artifacts. The private key never leaves the source machine; it proves identity. The public key can be shared and ends up in the server’s authorized list. During login, the server sends a challenge only the holder of the private key can answer.

Unlike passwords, keys are not guessable with brute force the same way. The math matters less for you than the properties: one key per system, revocable on the server side, no shared secrets via email, and no need to rotate credentials every 30 days.

Passphrases, agents, and storage

Adding a passphrase encrypts the private key at rest. On Linux/macOS, ssh-agent can cache the decrypted key in memory for your cron jobs. On Windows, Pageant (with PuTTY) or the built-in OpenSSH agent do similar work. For servers, a non-interactive store like system keyrings or a vault integration is cleaner.

Where you store the key matters. Keep it outside world-writable paths, lock down permissions (600 on UNIX), and avoid bundling it inside scripts or container images. If you use orchestration (systemd), set strict filesystem and environment permissions.

Key types and compatibility

Prefer ed25519 for new deployments. It’s compact, quick, and supported by modern OpenSSH. If your SFTP host only supports RSA, use rsa-sha2-512/256 and at least 3072 bits (4096 typical). Confirm supported algorithms on both ends before rollout, especially with managed SFTP vendors that lag upgrades.

Document the chosen key type in your runbook. This prevents someone six months later from generating an RSA key on their laptop while the server only accepts ed25519, causing silent job failures.

There are two dominant patterns: push and pull. In a push model, the source system packages data (e.g., a database dump, CMS export, or CRM report), then pushes it to an SFTP dropbox. In a pull model, a central orchestrator connects to each source and pulls data on schedule. Push is simpler to run; pull centralizes control and secrets management.

Hub-and-spoke works well at mid-size. A central backup host holds the private keys and schedules jobs, while each application has read-only export endpoints. The hub pushes data to a hardened SFTP target or cloud gateway. This keeps secrets in one place and simplifies rotation and monitoring.

Don’t forget the last mile. SFTP is transport. You still need encryption at rest, retention, and restore workflows. Many teams push to an SFTP inbox that feeds an object store (like S3) with lifecycle policies. If your provider offers an SFTP front-end to object storage, you can keep the simplicity of SFTP and the economics of object storage.

RPO and RTO drive everything. How much data can you afford to lose (RPO)? How fast do you need to recover (RTO)? If RPO is 24 hours, a nightly job is fine. If you need hourly RPOs, you’ll script incremental exports or binlog shipping and rethink transfer windows.

Retention and legal hold policies matter. Know how long you must retain backups for finance, tax, medical, or partner obligations. Set policies per dataset - marketing analytics might keep 180 days; finance keeps seven years. Configure pruning in code, not in someone’s memory.

Data classification guides scope. PII, PHI, and secrets need tighter controls: encryption at source, limited directory exposure on SFTP, IP allowlisting, and stricter monitoring. Log access attempts and keep immutable logs for audits.

Start by creating a dedicated, least-privileged account for backups on the SFTP server. Give it a chrooted home, SFTP-only shell (no SSH), and a specific upload directory. Then create a keypair on the source host (or central orchestrator) and register the public key.

Test interactively once with verbose flags. Capture the host key fingerprint on first connect and pin it. Then automate. Document each step in a runbook visible to whoever will be on-call next quarter.

Finally, tag every keypair in your inventory with owner, purpose, system, and expiration date. Keys without owners are future incidents.

Linux/macOS: create and register an ed25519 key

On the source machine (or orchestrator), run:

ssh-keygen -t ed25519 -a 100 -C "backup@yourcompany" -f ~/.ssh/backup_sftp
# -a 100 increases KDF rounds for passphrase-hardened keys

If you set a passphrase, load the key for non-interactive jobs via an agent or use a key-specific systemd unit that adds the key on boot. Share the public key (~/.ssh/backup_sftp.pub) with the SFTP admin. Keep permissions tight:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/backup_sftp ~/.ssh/config
chmod 644 ~/.ssh/backup_sftp.pub

Windows: OpenSSH or WinSCP

On modern Windows, you can use OpenSSH (built-in). Generate a key in PowerShell:

ssh-keygen -t ed25519 -a 100 -C "backup@yourcompany" -f $env:USERPROFILE\.ssh\backup_sftp

For scripting file transfers, WinSCP is popular. Convert keys to .ppk with PuTTYgen if needed and use a WinSCP script with a Scheduled Task. Pin the host key to avoid man-in-the-middle surprises.

Server-side hardening: authorized_keys and chroot

On the SFTP server, lock the account to SFTP and a specific directory. In OpenSSH’s sshd_config, you can use internal-sftp and ChrootDirectory to confine the user:

Match User backup
    ChrootDirectory /sftp/backup
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no
    PermitTTY no

In authorized_keys, you can further restrict the key:

from="203.0.113.10",no-agent-forwarding,no-port-forwarding,no-pty,no-X11-forwarding \
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... backup@yourcompany

Use the from="IP" guard to only allow known source addresses. For ultra-restricted use cases, pair the key with a forced command wrapper that validates paths and filenames before accepting uploads.

Automation is where good intentions become durable systems. Your script should: create a consistent backup artifact (e.g., database dump), compress and optionally encrypt it, transfer via SFTP, verify transfer success, and write structured logs. Then schedule it with cron (Linux/macOS) or Task Scheduler (Windows).

Here’s a minimal Bash example that dumps a Postgres database, compresses, and uploads via SFTP batch mode. It also prunes local temp files and writes logs that your monitoring can read:

#!/usr/bin/env bash
set -euo pipefail
TS=$(date +"%Y%m%d-%H%M%S")
BKPDIR=/var/backups/app
NAME=pgdump-${TS}.sql.gz
HOST=sftp.example.com
REMOTE_DIR=/inbox
LOG=/var/log/backup_sftp.log

mkdir -p "$BKPDIR"
pg_dump "${PGURL}" | gzip -c > "$BKPDIR/$NAME"
sha256sum "$BKPDIR/$NAME" > "$BKPDIR/$NAME.sha256"

cat > "$BKPDIR/sftp.batch" <<EOF
cd $REMOTE_DIR
put $BKPDIR/$NAME
put $BKPDIR/$NAME.sha256
EOF

if sftp -i ~/.ssh/backup_sftp -b "$BKPDIR/sftp.batch" backup@"$HOST"; then
  echo "${TS} OK $NAME" >> "$LOG"
  rm -f "$BKPDIR/sftp.batch"
else
  echo "${TS} FAIL $NAME" >> "$LOG"
  exit 1
fi

# Local retention
find "$BKPDIR" -type f -mtime +7 -name 'pgdump-*.gz' -delete
find "$BKPDIR" -type f -mtime +7 -name 'pgdump-*.sha256' -delete

On Windows with WinSCP, a simple script and Scheduled Task does the job. Example WinSCP script file (backup.txt):

option batch abort
option confirm off
open sftp://backup@sftp.example.com/ -privatekey="C:\\keys\\backup.ppk" -hostkey="ssh-ed25519 255 SHA256:YOURFINGERPRINT"
cd /inbox
put "D:\\backups\\*.gz"
exit

Then schedule: "C:\Program Files (x86)\WinSCP\WinSCP.com" /script="C:\scripts\backup.txt". Capture exit codes and log to Windows Event Log or a central aggregator. Alert on non-zero exits before end of business.

Key rotation should be boring. Keep a key inventory with owners and expiration dates. Support dual keys during rotation (old + new) to avoid downtime. Remove old keys immediately after a successful run with the new key. Automate these steps with a small playbook to cut human error.

Protect keys with least privilege. Restrict filesystem access (chmod 600), confine SFTP users with chroot, and disable interactive shells for backup accounts. On the network, allowlist source IPs and require known host fingerprints. If your SFTP provider supports it, use per-key upload-only policies.

Treat logs and verification as first-class. Keep structured logs of each run, include checksums, and store logs in an append-only location. Emit metrics (success/failure, duration, bytes transferred) to your monitoring stack. These artifacts are what you’ll show auditors - and what you’ll use to sleep at night.

Backups that haven’t been restored are assumptions. Schedule a monthly restore drill. Pull a random backup, verify checksums, restore into a staging environment, and run a few application-level checks (e.g., can you log in, is last week’s order present?). Log the drill and any remediation.

Implement canary files. Alongside your main backups, upload a small file with a predictable checksum. Your monitoring can fetch and verify this in seconds, providing early detection of path issues or permission changes without pulling gigabytes.

Alerting should hit the right person with the right context. Alerts that arrive at 3 a.m. without a runbook are noise. Include links to runbooks, recent changes, and responsible owners. Track mean time to detect (MTTD) and mean time to resolve (MTTR) for backup incidents like you would for production outages.

SFTP is a transport, not a full backup platform. It shines for file-based exports, movement between controlled networks, and when you need a standard protocol most vendors and partners will accept. Costs are low: a VM or managed SFTP endpoint, some storage, and operator time.

If you’re already standardized on cloud object storage, consider direct-to-object approaches (SDKs, rclone to S3/Blob) for higher throughput and lifecycle controls. That said, many business systems - from ERPs to legacy CRMs - natively speak SFTP. For those, SFTP keeps your integration surface small and your change risk low.

Rsync over SSH can be faster for incremental syncs of large directory trees. FTPS exists but adds certificate management complexity and is less universally accepted in secure enterprise environments. Backup software suites can add deduplication and block-level magic, but they come with licensing and a learning curve. Start from your RPO/RTO and data flow realities, not a vendor demo.

Permissions bite often. On UNIX, private keys must be 600 and the .ssh directory 700. If OpenSSH complains about unprotected key files, fix perms; don’t chmod 777 your way out. On Windows, ensure only the service account running the task can read the key files.

Host key pinning gets skipped. The first time you connect, record the server’s host key fingerprint out-of-band and pin it in scripts (WinSCP -hostkey, OpenSSH known_hosts). This prevents malicious or misconfigured middle boxes from intercepting traffic.

Line endings can break batch scripts. sftp -b expects LF, not CRLF. If you edit on Windows and deploy to Linux, normalize line endings. Also watch for special characters and spaces in filenames - quote your paths.

Backups aren’t just for engineering. Marketing systems hold high-value data: CRM exports, attribution logs, ad platform cost data, and offline conversion uploads. Losing a week of that can break cohort analyses, performance reporting, and sales follow-up SLAs. Treat these like production data and schedule exports the same way you would databases.

If your CRM or RevOps stack needs structured exports, wire them into a job that produces immutable daily snapshots and ships via SFTP to centralized storage. From there, your team can hydrate dashboards, run QA, and keep compliance happy. If you want help making your HubSpot/Salesforce data trustworthy end-to-end, see our CRM implementation and pipeline ops approach.

The same automation backbone you use for backups often powers enrichment, syncs, and handoffs between tools. SFTP jobs can be the reliable bridge between a data warehouse, finance, and your activation tools. Want the workflows built and maintained without another full-time hire? Our marketing automation work routinely includes robust export/backup processes as a first-class deliverable.

Anton Chisliuk · AI Marketing Ops is an operator model - one senior builder ships SEO, outbound, CRM, and automation without the agency tax. The work is production-first; e.g., we took Cleverence from 0 to ~80K organic visits/month and ~2K inbound leads/month with systems that keep running after the quarter ends. If you want the human behind the keyboard and transparent economics, learn more on our about page.

Backups that depend on a specific person eventually fail - vacations, turnover, or just a busy week. Harden the path: one-time key setup, scripted exports, pinned host keys, structured logs, and restore drills on a calendar. Then they’ll work for anyone on the team, not just the original author.

The fastest wins usually come from centralizing secrets and schedules, cutting manual exports from SaaS tools, and adding simple verification signals (checksums, canary files). Most of this is a few days of focused operator time, not a platform migration.

If you’d rather get the workflow shipped and documented while you stay on revenue work, this fits neatly inside our automation projects. See how we scope, build, and hand over production-grade workflows under Marketing Automation.

SFTP with private keys is not exciting. That’s the point. It’s a proven, auditable transport you can set up once, monitor, and forget - until you need it. Decide RPO/RTO, lock retention policies, generate per-system keys, pin host keys, automate transfers, and schedule restore drills. You’ll avoid “we thought it was backing up” surprises and cut subscription creep down to size.

If you want an operator to stand this up alongside your core marketing ops - CRM exports, analytics snapshots, ad spend reconciliations - book a free Growth Audit. We’ll map the fast path from ad hoc backups to a durable, testable pipeline.

Written by Anton Chisliuk - Leads, sales, content, and systems - one senior operator.

- Do I need a passphrase on the private key for automated backups?

It depends on risk tolerance. A passphrase protects the key at rest if the host is compromised. For automation, use an agent or a secrets store to provide the passphrase non-interactively. If you skip the passphrase, compensate with strict file permissions, host hardening, and IP allowlists.

- How often should we rotate SFTP keys?

Annually is a common baseline, or on personnel/system changes. Keep dual keys during rotation - add the new key, test a run, then remove the old key. Maintain an inventory with owners and expiry dates so rotations are routine, not fire drills.

- Our provider only supports RSA. Is that still safe?

Yes, with modern settings. Use RSA 3072 or 4096 and prefer rsa-sha2-256/512 signature algorithms. Avoid legacy SHA-1 signatures. If possible, push your provider to support ed25519, which is efficient and well-supported by recent OpenSSH versions.

- How do we verify we’re connecting to the right SFTP server?

Pin the host key. On first connection, obtain the host key fingerprint through a trusted channel (provider portal or ticket) and record it. In OpenSSH, add it to known_hosts; in WinSCP, use the -hostkey parameter. Fail closed if the fingerprint changes unexpectedly.

- What’s the difference between SFTP and FTPS for backups?

SFTP runs over SSH and uses key-based auth easily; FTPS runs over TLS and requires certificate management. SFTP is widely supported in enterprise file exchanges and simpler to harden with per-key restrictions. FTPS is viable but often more operational overhead.

- How can we prove backups are restorable to auditors?

Run scheduled restore drills. Log the date, dataset, checksum verification, restore time, and success criteria (e.g., application-level checks). Store these logs in an immutable location and reference them in your controls documentation.

- Can we add MFA to SFTP?

MFA isn’t typical for non-interactive SFTP automation. Instead, combine factors: key-based auth, IP allowlists, host key pinning, and restricted server-side commands/paths. For human, interactive SFTP sessions, you can enable MFA on SSH, but keep automation separate.

- How do we handle database backups vs. file backups?

Don’t copy live database files. Use logical dumps (pg_dump, mysqldump) or database-native snapshot mechanisms to create a consistent artifact, then transfer the dump via SFTP. For large datasets, consider compression, chunking, or pushing snapshots to object storage with lifecycle rules.

- What retention should we set?

Base it on RPO/RTO and compliance. Common patterns: daily for 30–90 days, weekly for 6–12 months, monthly for 1–7 years for finance. Implement pruning in scripts or storage lifecycle policies and document exceptions (e.g., legal holds).

- Our SFTP jobs randomly fail at night. What should we check first?

Check time windows (maintenance overlapping), network routes/ACLs, host key mismatches, disk space on source/target, and recent changes (key rotation, chroot paths). Enable verbose logs (sftp -vvv) and add retry with backoff to handle transient blips.