diff --git a/backup-to-drive.sh b/backup-to-drive.sh
index aa86e6a..abae2c7 100755
--- a/backup-to-drive.sh
+++ b/backup-to-drive.sh
@@ -61,7 +61,7 @@ done
 # which is how a ~275 KB JSON arrived truncated often enough to email a false alarm most
 # nights between 29 September and 8 October 2026. A pty does line discipline and has finite
 # buffers; it is not a file transfer. With a key there is no password prompt to automate, so
-# the file can come over scp and be byte-exact.
+# the file can be streamed over a plain ssh session and be byte-exact.
 #
 # The key lives on this machine only and is authorised on the NAS for this user. There is no
 # password here any more, and nothing to read out of the keychain.
@@ -132,7 +132,12 @@ else
     ok=0
     for try in 1 2 3; do
       : > "$TMP"
-      scp -q $SSH_OPTS "$NAS_USER@$NAS_HOST:$REMOTE_DIR/$f" "$TMP" 2>/dev/null || true
+      # `ssh cat`, not scp: this NAS has no SFTP subsystem, and modern scp speaks SFTP, so
+      # scp fails on every file with "subsystem request failed on channel 0". `scp -O` would
+      # work too but the legacy protocol is on its way out of OpenSSH. With key auth there
+      # is no pty in the way, so cat is byte-exact — verified against the NAS's own byte
+      # count. It was only ever the pty that corrupted this, never cat.
+      ssh $SSH_OPTS "$NAS_USER@$NAS_HOST" "cat $REMOTE_DIR/$f" > "$TMP" 2>/dev/null || true
     # scp delivers the file byte for byte, so there is nothing to slice out of a transcript
     # any more. The check stays because a backup that is present but unreadable is worse
     # than one that is obviously missing — it just verifies rather than repairs now.