How to Pass an SSH Password in a Script with sshpass and Expect

OpenSSH does not provide a --password option, and echo "password" | ssh ... does not satisfy the login prompt because the ssh command reads authentication input from a terminal rather than ordinary stdin.

Pick a tool by how interactive the session is:

• one password prompt — sshpass is the simplest helper
• several or changing prompts — Expect
• repeated production automation — SSH public-key authentication avoids storing account passwords in scripts

Quick answer

The shortest sshpass example people search for is:

sshpass -p 'secret' ssh user@server.example.com

That works in a one-off lab, but sshpass -p is the least safe password-source option:

• places the password on the command line at process startup
• can end up in shell history, scripts, and audit logs
• should stay in demos, not persistent automation

For a script, prefer a protected runtime secret with -d, -f, or -e rather than embedding the password after -p:

export SSHPASS='secret'
sshpass -e ssh user@server.example.com
unset SSHPASS

Why echo password | ssh does not work

OpenSSH deliberately collects sensitive prompts, including the login password, through the controlling TTY instead of stdin. Piping text into ssh does not feed that prompt.

This pattern fails for password login:

echo "$PASSWORD" | ssh user@server.example.com

The lab capture below forces the password authentication path so the failure is obvious. Those PreferredAuthentications and PubkeyAuthentication options are not required for normal sshpass usage:

echo 'secret' | ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no sshlab@127.0.0.1 hostname

Permission denied, please try again.
Permission denied, please try again.
sshlab@127.0.0.1: Permission denied (publickey,password).

sshpass and Expect work because they watch the pseudo-terminal for the password prompt and send the secret there. They do not rely on ssh reading the password from a pipe.

┌──────────┐      ┌─────────────────────┐      ┌──────────────┐      ┌──────────┐
│ sshpass  │ ───► │ watches PTY for     │ ───► │ ssh prompts: │ ───► │ sshd     │
│ wrapper  │      │ Password:           │      │ Password:    │      │ checks   │
└──────────┘      └─────────────────────┘      └──────────────┘      └──────────┘

sshpass makes SSH behave as if a human typed the password at the terminal prompt. That mental model matters more than trying to push the secret through stdin.

The stdin distinction matters:

• ssh — does not read login passwords from a pipe
• sshpass — reads a password from stdin when you omit -p, -e, -f, and -d

printf '%s\n' "$SSH_PASSWORD" | sshpass ssh user@server.example.com hostname

For scripts, -d is generally clearer when a process already has the secret available.

Method 1: Use sshpass

sshpass wraps ssh or scp, supplies the password when OpenSSH asks for it, and can return sshpass-specific exit codes when authentication or host-key checks fail.

Install sshpass

Package names match across distros, but the repository differs:

• Ubuntu / Debian — main archive (1.09 on current releases); install with the apt command: sudo apt install sshpass
• Fedora — standard repos; install with dnf: sudo dnf install sshpass
• RHEL / Rocky / AlmaLinux — often AppStream; if dnf install sshpass returns No match for argument, enable AppStream or use Ubuntu/Fedora for the lab

On the RHEL 10.2 host used for this article, sshpass 1.09-9.el10_0 came from AppStream:

dnf info sshpass

Name         : sshpass
Version      : 1.09
Release      : 9.el10_0
Repository   : rhel-10-for-x86_64-appstream-rpms
Summary      : Non-interactive SSH authentication utility

Confirm the binary after install:

sshpass -V

sshpass 1.09
(C) 2006-2011 Lingnu Open Source Consulting Ltd.
(C) 2015-2016, 2021 Shachar Shemesh
This program is free software, and can be distributed under the terms of the GPL
See the COPYING file for more information.

Using "assword" as the default password prompt indicator.

Basic password login

For everyday use, export the password once and call sshpass -e:

export SSHPASS='secret'
sshpass -e ssh user@server.example.com hostname
unset SSHPASS

sshpass forwards remaining arguments to ssh. You do not need extra -o flags unless you are deliberately forcing a specific authentication method.

The quick -p form is common in search results but should stay in demos:

sshpass -p 'secret' ssh user@server.example.com

Choose a password source: -d, -f, -e, -p

sshpass accepts the password from four built-in sources. A practical security-oriented order is:

A root-owned 0600 secret file can be preferable to an environment variable in some automation environments, so treat the table as guidance rather than a fixed rule.

Avoid putting the password on the command line: use a file descriptor

The sshpass manual recommends an anonymous pipe or file descriptor instead of -p. This keeps the password out of sshpass command arguments, but the secret still exists in:

• the shell variable from read
• process memory for the duration of the command
• the here-string behind file descriptor 3 until you close it

read -rsp "SSH password: " SSH_PASSWORD
echo

exec 3<<<"$SSH_PASSWORD"

sshpass -d 3 ssh user@server.example.com hostname

exec 3<&-
unset SSH_PASSWORD

For unattended jobs, replace the interactive read with your approved secret source.

Read the password from a protected file

Restrict the password file before sshpass reads it:

chmod 600 ~/.ssh/ssh-password

sshpass -f ~/.ssh/ssh-password ssh user@server.example.com hostname

The file becomes the secret. Restrict ownership and mode, and keep it out of backups you do not control.

Use the SSHPASS environment variable

After the first export SSHPASS='secret' example above, later sections assume SSHPASS is already set in the shell unless noted otherwise.

An environment variable is still a secret-bearing process resource. It is not a substitute for a vault or configuration-management secret store.

Run remote commands and SCP

Assuming SSHPASS is already set for this shell, run one remote command:

sshpass -e ssh user@server.example.com 'hostname'

Run several commands in one remote shell session:

sshpass -e ssh user@server.example.com 'hostname; uptime; id'

The same mechanism applies to scp because scp uses SSH authentication. Modern OpenSSH may prefer SFTP mode for scp, but password prompting still follows the SSH authentication path.

Assuming SSHPASS is already set:

• Upload — sshpass -e scp file.txt user@server.example.com:/tmp/
• Download — sshpass -e scp user@server.example.com:/var/log/app.log .
• Rsync over SSH — sshpass -e rsync -av -e ssh ./data/ user@server.example.com:/backup/ (see rsync command)

Lab verification on 127.0.0.1 adds client options only to force the password path for a reproducible capture:

sshpass -e scp /tmp/local.txt sshlab@127.0.0.1:/tmp/remote.txt
sshpass -e ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no sshlab@127.0.0.1 cat /tmp/remote.txt

lab scp test

Do not copy those PreferredAuthentications and PubkeyAuthentication=no flags into production unless you intentionally want to disable public-key fallback.

Keep host-key verification enabled

Password automation should not disable server identity checks by default.

Avoid making this the normal pattern:

-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null

That accepts any host key on every connection and removes MITM protection.

Host-key handling depends on how long you keep the server:

• Persistent infrastructure — verify the server host key out of band and populate ~/.ssh/known_hosts before automation runs
• Disposable lab hosts — trust-on-first-use may be acceptable:

sshpass -e ssh -o StrictHostKeyChecking=accept-new user@server.example.com hostname

accept-new adds a previously unknown host key but still refuses a host whose key has changed since you stored it. It helps only with new hosts; a key rotation on an existing host still stops the connection.

Common sshpass exit codes and troubleshooting

Before you blame sshpass, confirm the host is reachable and port 22 accepts connections with the layered checks in test an SSH connection.

sshpass defines its own exit statuses for password and host-key problems. Failures from the wrapped ssh or scp command may surface as SSH's own status, commonly 255 for a generic client failure. The table below is a quick subset, not an exhaustive list.

Wrong password on the lab host:

sshpass -p 'wrong' ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no sshlab@127.0.0.1 hostname

Permission denied, please try again.

Check the exit status immediately:

echo $?

5

Status 5 means sshpass detected bad credentials.

Unknown host key with strict checking:

No ED25519 host key is known for 127.0.0.1 and you have requested strict checking.
Host key verification failed.

Network failure looks different:

Connection timed out during banner exchange
Connection to 192.168.99.99 port 22 timed out

A non-zero exit status only tells you that something failed. Read the code and stderr together to separate:

• authentication (5 from sshpass, or Permission denied)
• host-key verification (exit 6/7, or Host key verification failed)
• networking (Connection timed out, Connection refused, or SSH exit 255)

Use verbose mode when a manual login works but automation stops:

sshpass -v -e ssh sshlab@127.0.0.1 hostname

SSHPASS: searching for password prompt using match "assword"
SSHPASS: read: 
sshlab@127.0.0.1's password: 
SSHPASS: detected prompt. Sending password.
SSHPASS: read: 

vm1.lab.example

Custom password prompts with sshpass -P

By default, sshpass searches for the substring assword so both Password: and password: match. When verbose mode shows a different prompt string, override the pattern with -P:

sshpass -e -P 'Enter passcode:' ssh user@server.example.com

Use -P only when authentication still involves one predictable prompt but the server uses text different from the normal Password: prompt. If authentication requires multiple prompts, use Expect instead.

Password versus keyboard-interactive authentication

OpenSSH can authenticate through either the password method or keyboard-interactive. They are separate SSH authentication methods, but sshpass can handle a simple password-style prompt from either mechanism because it watches the pseudo-terminal for a matching pattern.

The problem appears when keyboard-interactive authentication produces multiple or unusual prompts, such as:

• Password:
• Verification code:
• OTP:
• Enter token:

In that situation, sshpass may not be enough because it normally waits for a single password-prompt pattern. Use sshpass -P when only the prompt text differs, or Expect when the session needs responses to several different prompts.

Check what the server advertises:

ssh -vvv user@server.example.com

Look for a line such as one of these:

• Authentications that can continue: publickey,password
• Authentications that can continue: publickey,keyboard-interactive

PasswordAuthentication and KbdInteractiveAuthentication are configured independently in sshd. Either line can still work with sshpass when the session ends in one normal password-style prompt. See OpenSSH authentication methods in sshd_config for how those directives interact on the server.

On the server, inspect the effective settings with sudo:

sudo sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication'

passwordauthentication yes
kbdinteractiveauthentication yes

When passwordauthentication is no, the client cannot use the password method, but keyboard-interactive may still present a single password prompt that sshpass can answer.

Method 2: Use Expect

Use Expect when the session has more than one interactive prompt, or when prompts vary between hosts. For a single SSH password prompt, sshpass (or sshpass -P for custom prompt text) is usually enough.

Install Expect from the same package managers as sshpass:

• RHEL / Fedora / Rocky / AlmaLinux — sudo dnf install expect
• Ubuntu / Debian — sudo apt install expect

Handle multiple prompts

You only need four concepts for this example:

• spawn — start ssh
• expect — wait for output from the remote session
• send — type a response at the prompt
• eof — the remote process has finished

The script below expects SSH_USER, SSH_HOST, and SSH_PASSWORD to be set in the environment before it starts. If any variable is missing, Tcl throws an error immediately.

#!/usr/bin/expect -f

set timeout 15

if {![info exists env(SSH_USER)] || ![info exists env(SSH_HOST)] || ![info exists env(SSH_PASSWORD)]} {
    puts stderr "Set SSH_USER, SSH_HOST, and SSH_PASSWORD before running this script."
    exit 3
}

set user $env(SSH_USER)
set host $env(SSH_HOST)
set password $env(SSH_PASSWORD)

spawn ssh "$user@$host" hostname

expect {
    -re "(?i)password:" {
        send -- "$password\r"
        exp_continue
    }
    -re "Permission denied" {
        exit 1
    }
    -re "Connection refused" {
        exit 2
    }
    -re "Connection timed out" {
        exit 2
    }
    -re "Host key verification failed" {
        exit 4
    }
    timeout {
        exit 2
    }
    eof
}

Run it after exporting the connection details and reading the password once:

export SSH_USER=sshlab
export SSH_HOST=127.0.0.1
read -rsp "Password: " SSH_PASSWORD
export SSH_PASSWORD

./ssh-login.exp

unset SSH_PASSWORD SSH_USER SSH_HOST

spawn ssh sshlab@127.0.0.1 hostname

sshlab@127.0.0.1's password: 
vm1.lab.example

Do not pass the password as a third script argument. Command-line arguments are visible in ps output.

Handle authentication errors

The expect block above stops on explicit failure text instead of looping on repeated password prompts until eof:

• Permission denied — bad credentials or account policy
• Connection refused / Connection timed out — network or sshd not listening
• Host key verification failed — strict host-key checking blocked the session
• timeout — no prompt arrived within 15 seconds

That is still a teaching script, not production-grade error reporting, but it shows the control-flow model Expect expects: match prompts, send input, and exit on known failure strings.

Use Expect with SCP

Reuse the same password-prompt and error-handling block for scp:

spawn scp file.txt "$user@$host:/tmp/"

Match the same -re "(?i)password:" branch and let exp_continue run until eof or an explicit failure pattern matches.

Method 3: Use OpenSSH SSH_ASKPASS

OpenSSH can call an external askpass program when it needs a password. This answers searches for automating SSH without sshpass or Expect, but it takes more setup than sshpass -e.

OpenSSH selects an askpass helper in two main ways:

• Classic — no controlling terminal and DISPLAY is set
• Modern — SSH_ASKPASS_REQUIRE=force selects the helper even when a terminal exists

┌─────────────┐      ┌──────────────────┐      ┌─────────────────┐
│ ssh client  │ ───► │ SSH_ASKPASS      │ ───► │ helper prints   │
│ needs pass  │      │ helper program   │      │ password line   │
└─────────────┘      └──────────────────┘      └─────────────────┘

Create a helper that reads the secret from the environment:

cat > ~/bin/ssh-askpass-helper <<'EOF'
#!/bin/sh
printf '%s\n' "$MY_SSH_PASSWORD"
EOF
chmod 700 ~/bin/ssh-askpass-helper

Force askpass even when a TTY is present:

export MY_SSH_PASSWORD='secret'
SSH_ASKPASS=~/bin/ssh-askpass-helper SSH_ASKPASS_REQUIRE=force \
    ssh user@server.example.com hostname
unset MY_SSH_PASSWORD

On OpenSSH 9.9 in this lab, SSH_ASKPASS_REQUIRE=force invoked the helper without setting DISPLAY. When askpass is not selected:

• try DISPLAY=:0 as a compatibility hint for older graphical helpers
• confirm the helper path is executable and prints one password line on stdout

SSH_ASKPASS_REQUIRE also accepts prefer and never. Use force only when you understand that the helper program becomes the secret store.

Better long-term option: SSH keys

For scripts that run daily, public-key authentication is the better default. The automation process unlocks a key or uses an agent session instead of storing the remote account password.

Generate a modern key:

ssh-keygen -t ed25519

Install the public key on the server:

ssh-copy-id user@server.example.com

Connect without a password prompt when the key has no passphrase:

ssh user@server.example.com

When the private key has a passphrase, load it into ssh-agent for the current session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Pick the key model to match who unlocks it:

• Interactive or agent-backed runs — prefer a passphrase plus ssh-agent
• Unattended service automation — some environments use dedicated passphrase-less keys with tight filesystem permissions and server-side restrictions; treat those keys as high-value credentials

See SSH key authentication for authorized_keys layout, permissions, and troubleshooting, and generate SSH keys for algorithm choice.

Which method should you use?

Common mistakes

Summary

OpenSSH will not take a login password from a pipe because it reads sensitive prompts through the controlling terminal. That design choice explains most scripting failures that start with echo "$PASSWORD" | ssh.

When password automation is unavoidable, sshpass is the practical default for one SSH or SCP prompt. Prefer -d, -f, or -e over -p, keep host-key verification enabled, and remember that accept-new helps only with brand-new hosts. If manual login works but sshpass does not, check for multiple prompts or custom prompt text before you blame the password itself.

Expect belongs in the toolbox when prompts multiply or change shape. SSH_ASKPASS is legitimate OpenSSH plumbing, but the helper still holds the secret. For scheduled or large-scale automation, SSH keys with ssh-agent, or a proper secret-management workflow, remain the better long-term design.

References

• sshpass(1) — Debian manpages — password sources, exit codes, and security notes
• ssh(1) — SSH_ASKPASS, SSH_ASKPASS_REQUIRE, and client options
• Expect — Tcl Developer Xchange — spawn, expect, and send