How to Use the `scp` Command in Linux (A Simple Guide for Secure File Transfers)

When you work with Linux servers, sooner or later you hit the classic question: “How do I move this file from here to there without breaking anything?”
The scp command is one of the simplest answers. It uses SSH, works on almost every Linux box, and lets you move files securely between machines in the cloud hosting or web hosting world.
In this guide, we’ll go step by step, with real examples, so you can transfer files faster, more safely, and with less guesswork—whether it’s between two laptops or two production servers.

Why People Still Use scp

You already have plenty of ways to move files: FTP, SFTP, rsync, web UIs, even dragging files into some browser app.

But in real life, especially in the hosting and DevOps world, this is what often happens:

• You SSH into a Linux server.

• You realize a config file or script is on your laptop instead.

• You just want one simple command to send it over.

That’s where scp (secure copy) shines:

• It comes with OpenSSH on almost every Linux distribution.

• It uses the same SSH port and keys you already use to log in.

• It’s fast to type and easy to script.

No extra daemons, no extra services, no new port to open in the firewall. Just you, your terminal, and a file that needs to move.

What You Need Before Using scp

To follow along, you only need:

• Two Linux machines (could be your laptop + a remote server).

• SSH installed and running on the remote machine.

• A username and password (or SSH key) for the remote machine.

• The IP address or hostname of the remote machine.

If you rent dedicated servers or cloud servers, this is already standard. You get:

• A public IP

• A Linux distribution (Ubuntu, Debian, CentOS, etc.)

• SSH access

If you want a simple playground for practicing scp between real Linux servers, it helps to have fast, ready-to-use machines that behave like production hardware.
👉 Set up a GTHost server in minutes and practice scp between real Linux machines
This way, you don’t just read about secure copy—you actually move files around the same kind of servers you’d use in real projects.

The Basic scp Pattern

Under all the examples, scp works like this:

bash
scp [options] source destination

The important idea:

• A local path looks like:
  /home/user/file.txt

• A remote path looks like:
  user@server_ip:/remote/path/file.txt

You can think of it as:

“Take this file from here, and copy it to there.”

If one side has user@host:, that side is remote; the other side is local.

Example Setup We’ll Use

Let’s imagine:

• Your local machine username: alice

• Remote machine IP: 192.168.1.30

• Remote username: also alice (we’ll change it later)

We’ll move a file called zdnet_test around. You can replace that with any file name you like.

1. Push a File from Local to Remote (Same Username)

You’re sitting at your local terminal. You have a file at:

bash
/home/alice/zdnet_test

You want to send it to the remote server 192.168.1.30 into /home/alice/.

Run:

bash
scp /home/alice/zdnet_test 192.168.1.30:/home/alice

What happens next:

• scp connects to 192.168.1.30 over SSH.

• It assumes the same username (alice) because you didn’t specify one.

• It prompts you for the password of alice on the remote machine (unless you use SSH keys).

• After you type the password, it copies the file.

If the path is wrong, you’ll get an error like “No such file or directory.”
If the password is wrong, SSH will complain. That’s normal. Fix the typo, try again.

2. Push a File When the Remote Username Is Different

Now change the story: your local username is alice, but on the remote server you log in as deploy.

The only change in the command is the user@ part before the IP:

bash
scp /home/alice/zdnet_test deploy@192.168.1.30:/home/deploy

Breakdown:

• /home/alice/zdnet_test is the local source file.

• deploy@192.168.1.30:/home/deploy is the remote destination.

You’ll now be prompted for the password of deploy on 192.168.1.30.

You can also change the remote directory. For example, send the file to /data instead:

bash
scp /home/alice/zdnet_test deploy@192.168.1.30:/data

Same story, different target folder. As long as deploy has permission to write to /data, it will work.

3. Pull a File from Remote to Local

Sometimes the file lives on the server and you want it on your machine. That’s “pulling” a file.

You’re still on your local machine. On the remote server, the file is here:

bash
/path/to/zdnet_test

You want it to end up in:

bash
/home/alice/zdnet_test

Run:

bash
scp 192.168.1.30:/path/to/zdnet_test /home/alice/zdnet_test

Or with an explicit username:

bash
scp deploy@192.168.1.30:/path/to/zdnet_test /home/alice/zdnet_test

Again:

• You’re prompted for the remote password.

• After success, you’ll find zdnet_test in your local /home/alice/ directory.

This is perfect for:

• Pulling log files for debugging

• Downloading backups

• Copying configuration files to review locally

4. Copy Directories with scp -r

Very quickly, you’ll want more than one file. You want a whole directory: scripts, configs, assets.

That’s where the -r (recursive) flag comes in:

bash
scp -r /home/alice/project deploy@192.168.1.30:/home/deploy/

This copies the entire project folder and everything under it.

A few notes:

• -r can be used in both directions (local → remote, remote → local).

• Large directories can take time—watch the progress bar.

• Make sure you don’t accidentally overwrite something important on the remote side.

5. Use a Custom Port or SSH Key

In real-world hosting and cloud environments, SSH is often not on the default port 22, or you use SSH keys instead of passwords.

Use a Non-Default SSH Port

If your SSH server runs on port 2222, use -P:

bash
scp -P 2222 zdnet_test deploy@192.168.1.30:/home/deploy

(Uppercase -P, not lowercase.)

Use an SSH Key

If you log in with a key file, use -i:

bash
scp -i ~/.ssh/id_rsa zdnet_test deploy@192.168.1.30:/home/deploy

You can combine them:

bash
scp -i ~/.ssh/id_rsa -P 2222 zdnet_test deploy@192.168.1.30:/home/deploy

Now you’re using:

• SSH key for authentication

• Custom port for the connection

This is closer to how people manage real servers in the web hosting and cloud hosting industry.

6. Common scp Mistakes (And Quick Fixes)

Everyone hits the same few walls starting out. Here are the usual suspects.

“No such file or directory”

• Check the local path:
  ls /path/to/zdnet_test

• Check the remote path (from an SSH session):
  ls /home/deploy

One typo in the path and scp gives up.

“Permission denied”

On remote:

• The user doesn’t have permission to write to the target directory.

• Try a directory under the user’s home, like /home/deploy/.

On local:

• Maybe your local user can’t read the source file.

• Fix permissions with chmod or run scp from a user that can read it.

Forgot the colon

This is a classic:

bash
scp zdnet_test deploy@192.168.1.30/home/deploy

You forgot the colon after the host. It should be:

bash
scp zdnet_test deploy@192.168.1.30:/home/deploy

Without the colon, scp thinks the whole string is a local path.

7. When scp Is a Good Fit (And When It’s Not)

scp is great when:

• You just need to move some files now.

• You’re already using SSH and don’t want extra setup.

• You need something simple to script for deployments or quick backups.

If you need advanced syncing, bandwidth control, or resuming huge transfers, tools like rsync might fit better. But most day-to-day Linux admin tasks—especially on small to medium projects—can be handled by scp without stress.

And if you’re working with multiple remote servers (testing, staging, production), having stable, always-on machines makes this even smoother. That’s where the choice of hosting provider quietly affects your day-to-day file transfers.

Conclusion

Using the scp command in Linux is much easier than it looks at first glance. Once you understand “source → destination” and how to point at a remote path with user@host:/path, you can push and pull files between Linux servers quickly, securely, and with less friction in your daily work.

In real hosting and DevOps environments, having reliable servers plus simple tools like scp keeps your deployments and maintenance lean. If you want to see why GTHost is suitable for Linux remote file transfer scenarios—with instant servers that are ready for SSH and scp out of the box—take a look here:
👉 why GTHost is suitable for Linux remote file transfer scenarios

Get comfortable with scp now, and moving files around your Linux infrastructure will feel a lot less like a chore and more like a quick, reliable part of your workflow.