Look for SSH errors, process crashes, out-of-memory kills, storage errors, and
reboots at the failure time. A full filesystem or exhausted inodes warrants
investigation, but does not by itself explain a TCP reset. If the VM becomes
unreachable, inspect its EC2 status checks and console output through AWS.
### 2. Test bulk SSH traffic without SCP or destination-file writes
Run on the Mac, using the variables from the setup block:
```bash
time ssh -T -v -i "$ssh_key""$remote_target"'wc -c' < "$source_file"
transfer_status=$?
printf'SSH exit status: %s\n'"$transfer_status"
```
The remote process counts and discards the incoming bytes. It does not save the
archive. Success means the printed count matches the local `wc -c` result and
SSH exits with status zero; for release 0.2.1 the count is `240799305`.
| Result | Interpretation and next action |
| --- | --- |
| Connection resets | SCP, SFTP, and destination-file writes are unnecessary to trigger the failure. Investigate SSH, server health, and the network path. |
| Repeated success | Investigate the file-transfer process and destination storage. Repeat the failing SCP command while observing server logs. |
| Observer SSH session also disconnects | Check for a broader network interruption, VM restart, or service failure. |
| Observer SSH session survives | Investigate behavior specific to the transfer connection or its workload. |
### 3. Compare an independent network
Repeat the exact byte-count command through a phone hotspot or another
independent network. If a VPN is active, separately compare with it disconnected
where practical. Verify that the test network's public IP is permitted by the
VM's existing SSH access rules; an access-denied or connection-timeout result
does not test bulk-transfer behavior.
Consistent failure on one network and success on another is strong evidence of
a path-dependent issue. Candidate components include the router, VPN, firewall,
ISP path, and local network filtering. The comparison does not identify which
component is responsible.
### 4. Isolate packet-priority handling
On the failing network, repeat the byte-count test with only `IPQoS=none` added:
```bash
time ssh -T -v -o IPQoS=none -i "$ssh_key"\
"$remote_target"'wc -c' < "$source_file"
transfer_status=$?
printf'SSH exit status: %s\n'"$transfer_status"
```
`IPQoS=none` uses the operating system's default packet-priority marking.
OpenSSH 10.1 changed QoS handling, making a controlled comparison relevant to
the OpenSSH 10.2 client. A repeatable improvement warrants examination of packet
marking and network handling; it does not identify a defective component.
See the [SSH option documentation](https://man.openbsd.org/ssh_config#IPQoS)
and [OpenSSH 10.1 release notes](https://www.openssh.org/txt/release-10.1).
### 5. Follow the evidence
- If failures follow the network, compare VPN/router/filtering configurations
and, if needed, capture TCP traffic at both endpoints to investigate resets
and retransmissions. A reset observed only at the client can indicate an
intermediary; account for capture coverage before drawing conclusions.
- If server logs identify a crash, resource shortage, or SSH error, investigate
that specific failure before changing algorithms or timeout settings.
- If bulk SSH repeatedly succeeds, reproduce SCP with verbose logging and
inspect the destination filesystem and transfer process:
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
