Moving files between Linux servers sounds simple until the scp command stops your script and waits for a password. If you manage cloud hosting, dedicated servers, or any Linux infrastructure, those little password prompts can break backups, deployments, and late-night automation.
In this guide, we’ll walk through how to use the SCP command with a password using sshpass, so you can automate file transfers, keep things secure enough for real-world use, and cut down on repetitive work.
Think of scp (secure copy) as cp with a passport. It copies files:
From your local machine to a remote server
From a remote server back to your local machine
Between two remote servers, triggered from your local machine
All over SSH, encrypted, nothing fancy to set up.
You’ve probably seen something like this:
bash
scp filename user@remotehost:/directory/path
That’s you saying: “Take filename from here and put it on that server, in that directory.”
Copy file1.txt from your laptop to a remote Linux server at 192.168.1.100, into /mnt:
bash
scp file1.txt [email protected]:/mnt/
Copy file1.txt from the same remote server back to your local /opt directory:
bash
scp [email protected]:/mnt/file1.txt /opt/
In both cases, SCP will ask for the remote user’s password:
text
[email protected]'s password:
That’s fine when you’re typing commands by hand. It’s a disaster when you want fully automated scripts.
Interactive passwords are okay when you’re:
Logging into a dev box
Copying a one-off file
Fixing something quickly at the console
But they’re a problem when you want to:
Run cron jobs for nightly backups
Sync logs between servers
Deploy build artifacts to multiple nodes
Script migrations across your hosting environment
Any time scp waits for a password, your script stops. No password, no copy, no automation.
If you’re doing this on top of cloud hosting or dedicated servers, you want the servers to run quietly in the background and just do their job. You don’t want to babysit every single file transfer.
And if you’re frequently moving data between production boxes, it also helps a lot to be on stable, dedicated infrastructure with good network performance. That way your automation is limited by your scripts, not by flaky servers.
👉 Try GTHost instant dedicated servers built for fast, stable Linux SCP and backup automation
With a solid hosting base and a bit of scripting, SCP suddenly becomes a lot more predictable—and that’s really what you want in production.
Before we bring in sshpass, there’s an important note:
The best practice for SSH and SCP automation is SSH keys, not passwords.
Tools like sshpass literally put passwords in commands or scripts, which can be risky if you’re not careful.
Use sshpass when:
You’re in a lab, demo, or test environment
You’re dealing with legacy systems that don’t support keys easily
You need a quick temporary workaround
Don’t use sshpass as your long-term security strategy for critical production systems if you can avoid it.
sshpass is a small command-line tool that lets you feed a password into any SSH-based command (like ssh or scp) non-interactively.
It’s not installed by default on most Linux distributions, so you need to add it.
bash
sudo apt-get update
sudo apt-get install sshpass -y
bash
sudo dnf install sshpass -y
Once that finishes, you’re ready to glue sshpass onto scp.
Here’s the general idea:
bash
sshpass -p "remote-user-password" scp filename user@remotehost:/dir/path/
You run sshpass, give it the password, and then sshpass runs scp for you, handling the password prompt behind the scenes.
Copy file1.txt to 192.168.1.100 into /mnt, and pass the password automatically:
bash
sshpass -p "password" scp file1.txt [email protected]:/mnt/
Same SCP behavior, but no interactive password prompt.
Copy /mnt/file1.txt from the remote server back to your local /opt:
bash
sshpass -p "password" scp [email protected]:/mnt/file1.txt /opt/
Again, the transfer just runs. No prompt, no waiting.
Where sshpass really becomes useful is inside shell scripts and cron jobs.
Let’s say you want to back up /var/log from a remote server to your backup server every night.
bash
#!/usr/bin/env bash
REMOTE_USER="backupuser"
REMOTE_HOST="192.168.1.100"
REMOTE_PATH="/var/log/"
LOCAL_PATH="/backups/logs/"
REMOTE_PASS="password"
sshpass -p "$REMOTE_PASS" scp -r "${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_PATH}" "$LOCAL_PATH"
Make it executable:
bash
chmod +x backup_logs.sh
Add to cron (for example, to run at 2:30 AM):
bash
crontab -e
Add a line:
bash
30 2 * * * /path/to/backup_logs.sh >/var/log/backup_logs.log 2>&1
Now your script runs automatically, uses SCP with a password, and does not stop for input.
Avoid hardcoding passwords in public repos.
If this is anything beyond a lab, keep scripts private.
Limit user permissions.
Use a dedicated user with only the access it absolutely needs.
Consider environment variables or a root-only file
for storing the password, if you must use sshpass in more serious setups.
If you find yourself:
Managing multiple production Linux servers
Running lots of SCP or SSH automation
Working across a complex hosting environment
Then SSH keys with proper key management will make your life easier:
More secure than plain passwords
No need to store passwords in scripts
Easier to rotate access when people join/leave the team
You can still keep sshpass as a temporary tool or for edge cases, but long-term, SSH keys are the way to go for professional server and cloud hosting operations.
Using the SCP command with passwords in Linux becomes much more manageable once you add sshpass into the mix. It lets you automate SCP transfers, support cron jobs, and keep your Linux hosting workflow running smoothly without staring at password prompts.
For teams that move a lot of data between servers, a stable dedicated hosting platform matters just as much as good tooling—👉 see why GTHost is suitable for SCP-heavy Linux server scenarios and fast automated deployments. With reliable infrastructure plus simple tools like sshpass, your daily server operations become faster, more predictable, and much less painful.