Copy files through an authenticated SSH service

Needs: Reachable SSH/SFTP service, correct key/password and read/write rights; client/server subsystem compatibility

Kali to a Linux target

# Kali to a Linux target
scp FILE USER@TARGET:/tmp/FILE

# Run from Kali when the target's SSH service is reachable
scp USER@TARGET:/path/to/FILE ./FILE

# SSH key or nonstandard port
scp -i KEY -P PORT FILE USER@TARGET:/tmp/FILE

Verify → Verify copied bytes and location; uppercase -P selects scp's SSH port.

If it fails → Authentication failure, missing subsystem and destination permission failure need different changes. Prefer a supported transfer method over guessing flags. More detail ↓

If → then

A downloaded/generated artifact exists but does not run → Match an artifact to its executable consumer and runtime
Needs: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format
A tool/artifact must reach a target that can make an HTTP request → Transfer over HTTP using Linux or Windows clients
Needs: Correct server bind and served directory; target-to-server route, available downloader and writable destination
An SSH service and a known password, private key or agent context → Use SSH passwords, keys and forwarding-capable access
Needs: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Copy files through an authenticated SSH service

USE WHEN: An SSH identity can access the needed source/destination
STARTING ACCESS: Verified command execution or authenticated remote access and a known network path
RESULT: An authenticated file copy with verified bytes

Recognize the clue

Use established SSH context to identify allowed file/subsystem access and the intended remote destination's rights.

ssh -v -p PORT USER@TARGET

SYNTHETIC EXAMPLE OUTPUT

Authenticated using publickey
Session/subsystem policy: inspect before transfer

Means: SSH authentication gives a candidate transport; it does not prove SFTP/subsystem support or destination write.

Confirm: Validate client/server subsystem compatibility, source read and destination write; inspect resulting bytes.

After validation: The supported copy mode writes the intended file and hashes match: use SCP.
Ruled out in this context: The destination is unwritable: reject that path while retaining SCP to a permitted directory.
Still inconclusive: Accepted SSH without subsystem evidence leaves transfer behavior unknown.

Troubleshooting: Authentication failure, missing subsystem and destination permission failure need different changes. Prefer a supported transfer method over guessing flags.

Additional prerequisite checks

ssh -p PORT -i KEY USER@TARGET

SCP — copy through an authenticated SSH service

Kali to a Linux target

Linux target to Kali

Run from Kali when the target's SSH service is reachable:

SSH key or nonstandard port

scp uses uppercase -P for the SSH port. Authentication success does not guarantee write permission at the destination path.

Why it works

SCP uses SSH authentication but filesystem rights remain independent. Modern clients may use the SFTP subsystem; a restricted service can allow one access form and deny another.

Worked example · hypothetical

Observation: SSH login succeeds but copying into an application directory fails. Test: copy to the user's writable temporary directory. Illustrative output: transfer completes and hashes match. Interpretation: destination authorization caused the original failure.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗