SCP legacy protocol compatibility
scp legacy protocol option becomes manageable when the investigation identifies the last successful SSH boundary before changing configuration.
TL;DR: Modern scp uses SFTP by default, but an older server or unusual shell expects legacy SCP behavior and fails differently. Test SFTP directly, update the older endpoint when possible, and use -O only for the named legacy target with explicit paths.
Audience: developers, founders, homelab users, and on-call operators with basic command-line familiarity. Read every command, replace example names, and keep a recovery path before changing access.
What scp legacy protocol option means
Modern scp uses SFTP by default, but an older server or unusual shell expects legacy SCP behavior and fails differently. This is narrower than “SSH is broken.” It identifies a boundary that can be tested without rotating every key, restarting every service, or disabling a security control.
SSH crosses name resolution, TCP transport, protocol negotiation, host verification, user authentication, channel creation, and the remote program. Record the last stage that succeeded and the first line that contradicts the expected path.
Diagnostic and rehearsal path
Some commands below create or alter test artifacts. Run them only with disposable paths on a non-production or recoverable system, and inspect each command before execution:
scp -vvv file user@example-host:/tmp/; scp -O -vvv file user@example-host:/tmp/; sftp -vvv user@example-host; ssh user@example-host 'command -v sftp-server; printf ok'Record the UTC time, target, exit status, and first decisive line. Do not paste private keys, passphrases, tokens, complete environment dumps, or unredacted authentication logs into a shared transcript.
Interpret the evidence
- Since OpenSSH 9.0, scp normally uses SFTP rather than its historical protocol.
- The -O flag forces legacy SCP and should be a scoped compatibility tool.
- Shell metacharacter and wildcard behavior differs between local, SFTP, and legacy remote-shell expansion.
- Recent OpenSSH releases include security fixes specifically for SCP path handling.
- If a text configuration and runtime output disagree, effective configuration and timestamped runtime logs win.
If two observations conflict, effective configuration and timestamped runtime evidence outrank a remembered file. A successful client-side check does not prove that a server, identity provider, cloud firewall, or second SSH hop agrees.
Choose the platform boundary
Linux distributions, macOS, Windows, WSL, cloud VMs, containers, CI runners, VS Code, Tailscale, NAS appliances, and bastions expose different authorities and recovery routes. Use the SSH platform diagnostics guide for the relevant environment instead of applying every platform command to one host.
Decision tree
- Confirm identity and destination. Expand the configuration and verify hostname, port, user, address, and selected credential.
- Classify the boundary. Decide whether the evidence belongs to client state, network transport, SSH negotiation, authentication, session setup, or the invoked program.
- Consult the authority. Use the topic source below and the platform diagnostics guide for current behavior.
- Reproduce once. Match one client attempt to one server or platform event by UTC time and source address.
- Disprove the leading explanation. Name one observation that would make it wrong.
- Prepare recovery. Keep an existing session, provider console, physical path, or second administrator available.
- Apply one narrow change. Test SFTP directly, update the older endpoint when possible, and use -O only for the named legacy target with explicit paths.
- Verify externally. Repeat the original user action from a fresh connection and check adjacent security controls still work.
Repair and rollback
Before changing access, capture effective configuration and relevant file metadata. For sshd changes, validate syntax using the platform-supported method before reload. For credentials, record fingerprints rather than secret material. For routing and forwarding, write both endpoints and listening addresses explicitly.
The topic-specific caution is: Do not make legacy mode a global alias; it reintroduces fragile remote-shell parsing and older risk. A rollback must use a path independent of the control being edited. An SSH command that reverts sshd is not a recovery plan when sshd no longer accepts connections.
After recovery, remove temporary exceptions, expire test credentials, close unused forwards, and record ownership. NIST's SSH access-management guidance emphasizes provisioning, termination, and monitoring because unattended keys and forgotten machine access outlive the incident that created them.
Investigate it in Tryssh
$ ssh -G example-host | sed -n '1,24p' Capture the first decisive result, timestamp, and exit status.
Tryssh separates the copilot's SSH execution channel from the visible terminal. Read-only commands must pass a default-deny risk gate; state-changing commands remain explicit human approvals. That helps organize evidence, but it does not make Tryssh the incident owner or remove the need for independent recovery.
Common operator questions
Is the first error line always the root cause?
No. It is a boundary marker. Correlate it with effective configuration, the same timestamp on the other endpoint, and the platform control plane. The loudest log line may be old or unrelated.
Can Tryssh apply the repair automatically?
It can accelerate read-only evidence collection and draft a precise repair. Authentication, firewall, certificate, account, forwarding, and service changes should remain explicit approvals because their blast radius extends beyond one terminal.
Should this setting be changed globally?
Usually not for an initial repair. Prefer a host, user, Match block, key, or single workflow scope. Expand only after a canary succeeds and the compatibility/security trade-off is documented.
When should the investigation stop?
Stop before changing access if there is no independent recovery path, the target identity is uncertain, or the evidence requires exposing secrets. Establish the missing boundary first.
Evidence and review status
This page consolidates twenty-five platform-targeted drafts into one canonical problem guide. Its commands and claims were checked against the linked upstream and platform sources. Only explicitly labeled reproduced output is presented as first-hand evidence; use the platform guide and current first-party documentation before executing a repair.
Limits and trade-offs
Managed services can replace local SSH files with IAM, metadata, policy, or generated configuration. Verbose output can expose users, hostnames, paths, fingerprints, and topology. A one-host success is evidence, not permission for a fleet rollout; use canaries, stop conditions, bounded concurrency, and independent rollback.
Related Tryssh guides
Continue with SCP no such file or directory, Rsync over SSH exit code 23, the SSH platform diagnostics guide, SSH config guide, and SSH hardening checklist.