Skip to content
eSHARS Operations

INFRA-0008: Keep CrushFTP for SFTP, Pause SFTPGo Migration

Status

Accepted — CrushFTP remains the live SFTP server (hardened in place); the SFTPGo migration is paused with Terraform code retained for a possible future move (2026-06-15)

Date

2026-06-15

Context

The production SFTP server vm-eshars-sftp (Windows Server 2019, CrushFTP 10.8.5) handles all district file exchange. A replacement on SFTPGo (Ubuntu 24.04) had been in progress under DEVOPS-156, driven primarily by a belief that the existing server was a significant security exposure.

A June 2026 security review (see CrushFTP Hardening — June 2026) changed that premise:

  • CrushFTP 10.8.5 is patched against the known actively-exploited CVEs (CVE-2025-31161 auth bypass, CVE-2024-4040 RCE). It is not the open hole it was assumed to be.
  • The actual exposure was network-level — the CrushFTP admin web ports were reachable far too easily — which was closed with explicit NSG denies, leaving only SFTP (port 22) exposed.
  • The license is paid and current.

With the security emergency removed, the SFTPGo migration’s remaining value is strategic, not urgent: getting off Windows Server 2019, off CrushFTP licensing, and onto Terraform-managed infrastructure.

Decision

  1. Keep CrushFTP on vm-eshars-sftp as the live SFTP server, hardened in place (NSG lockdown done; admin-account MFA pending, owner-driven).
  2. Pause the SFTPGo migration. Do not run a cutover at this time.
  3. Retain the SFTPGo Terraform code (infrastructure/vms/eshars-sftp/ and the extended modules/linux-vm) for a future, deliberately-scheduled move if a cost or modernization case justifies it.
  4. Tear down the deployed SFTPGo nonprod VM (vm-eshars-sftp-np-cus) so no idle compute is billed. Code remains; the deployed instance does not.

Consequences

  • Positive: no migration risk or cutover coordination now; security gap closed cheaply; SFTPGo work preserved and proven (the nonprod build was validated end-to-end before teardown), so a future migration is low-friction.
  • Negative / accepted: the workload stays on Windows Server 2019 and continues to incur CrushFTP licensing. These are the modernization items deferred, to be revisited if a cost/EOL case emerges.
  • Follow-up: MFA enrollment on esharsadmin and hisd-admin remains open.

Reference state of the SFTPGo work (as of this decision)

  • infrastructure/vms/eshars-sftp/ — full Terraform root (nonprod + prod), kept.
  • The deployed vm-eshars-sftp-np-cus and its 5 associated resources were deleted 2026-06-15; the nonprod tfstate now reflects no live resources.
  • Migration runbook (accounts + 36 GB data, full lift-and-shift to both tiers) documented in the root’s README.md.

Update — 2026-06-23 (post-teardown)

The decision (keep CrushFTP, pause SFTPGo) still stands, but two facts changed in the 2026-06-17 estate teardown:

  • vm-sftp-prod-001 was destroyed along with the rest of the torn-down estate. It is no longer a deallocated “reference” VM — the 36 GB of district data and the SFTPGo SQLite account DB that the migration runbook depended on no longer exist. If the SFTPGo migration is ever resumed, the source of truth is now CrushFTP (vm-eshars-sftp) directly, not the prototype.
  • The Terraform code (infrastructure/vms/eshars-sftp/) was meanwhile updated by the rebuild to CAF naming (rg-eshars-compute-{tier}-cus, pinned IP .11), so it stays deployable — but the data/account-migration plan in the README is now void and would need re-derivation from the live CrushFTP server.

Net effect: the pause is now effectively a clean slate. A future migration would seed from CrushFTP, not restore prototype state.