Introduction

sshpass and SSH private keys solve two different authentication problems, and mixing them often creates confusing behavior. When an SSH command appears to hang, the usual cause is not a frozen network session but an interactive prompt that your automation is not equipped to answer.

Why sshpass and Private Keys Clash

sshpass is designed to feed a password to a program that expects password-based authentication. Private-key authentication works differently. SSH first tries the key, may ask for a key passphrase, may ask for host-key confirmation, and may fall back to password authentication depending on server policy and client options.

That means a command like this is structurally suspicious:

sshpass -p 'secret' ssh -i ~/.ssh/id_ed25519 [email protected]

There are several possible outcomes:

• The key authenticates successfully, so sshpass was unnecessary
• The private key is encrypted, and SSH prompts for the key passphrase instead of the login password
• The host key is unknown, and SSH waits for a trust confirmation
• The server rejects the key, and SSH falls through to another auth method

From the outside, all of those can look like "it hangs."

Use One Authentication Strategy at a Time

If you want key-based login, use SSH directly and make it fail fast in automation:

1ssh -i ~/.ssh/id_ed25519 \
2  -o BatchMode=yes \
3  -o PreferredAuthentications=publickey \
4  [email protected]

BatchMode=yes tells SSH not to prompt interactively. If the key cannot be used, the command exits with an error instead of waiting for input.

If the private key itself is passphrase-protected, the usual fix is not sshpass. The fix is ssh-agent:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh -o BatchMode=yes [email protected]

You enter the key passphrase once when loading the key into the agent. Later SSH commands can reuse the unlocked key non-interactively.

If you truly need password authentication, disable key auth explicitly so SSH does not waste time attempting the wrong mechanism:

1export SSHPASS='server-password'
2sshpass -e ssh \
3  -o PubkeyAuthentication=no \
4  -o PreferredAuthentications=password \
5  [email protected]

This makes your intent clear to the client.

Other Prompts That Look Like Hangs

Authentication is not the only issue. SSH can pause because it is waiting for input unrelated to your password.

A common example is the first connection to a host:

The authenticity of host 'example.com' can't be established.
Are you sure you want to continue connecting?

In a non-interactive environment, that prompt blocks progress. If you already manage host keys safely, pre-populate known_hosts or use an appropriate StrictHostKeyChecking policy for your environment.

Another cause is a remote command that expects a terminal. In that case the SSH session is established, but the remote side is waiting on interactive input. That is different from an authentication stall.

Debugging the Real Failure

Run SSH in verbose mode before changing too many flags. The debug logs usually show exactly where the process stops.

ssh -vvv -i ~/.ssh/id_ed25519 [email protected]

Look for lines that reveal the phase:

• Host-key verification
• Public key offered
• Public key rejected
• Password authentication attempted
• Keyboard-interactive challenge

If you must inspect sshpass behavior, keep the SSH debug flags:

SSHPASS='server-password' sshpass -e ssh -vvv \
  -o PubkeyAuthentication=no \
  [email protected]

That combination usually makes the source of the pause obvious.

Safer Automation Patterns

For unattended jobs, key-based authentication with an agent or dedicated deployment key is normally the right answer. It is more predictable and avoids embedding server passwords in scripts, process lists, or logs.

If you are inside CI, prefer one of these patterns:

• Inject a private key as a secret, write it with restrictive permissions, and use ssh-agent
• Use an ephemeral runner image with the host key already trusted
• Set BatchMode=yes so jobs fail clearly instead of hanging forever

Also consider timeouts. A network issue can look similar to an auth prompt when the script provides no logging. Wrapping SSH with a timeout makes failures easier to diagnose.

timeout 20 ssh -o BatchMode=yes -i ~/.ssh/id_ed25519 [email protected]

Common Pitfalls

The most common mistake is expecting sshpass to unlock an encrypted private key. That is not what it is built for. It supplies login passwords, not key passphrases in a general, reliable way.

Another mistake is leaving multiple authentication methods enabled. SSH will try methods in order, and the fallback behavior can make the session appear inconsistent from one host to another.

Developers also forget about host-key prompts. The SSH command is not actually frozen; it is blocked waiting for trust confirmation that your non-interactive script cannot provide.

Finally, avoid using password automation when key-based access is available. Even when it works, it is usually less secure and harder to maintain.

Summary

• 'sshpass is for password authentication, not for general private-key handling.'
• If you use a private key, prefer ssh-agent plus BatchMode=yes.
• Disable public-key auth explicitly when you truly want password-based login.
• Use ssh -vvv to see whether the pause is caused by keys, passwords, or host-key verification.
• For automation, choose one auth mechanism and make it fail fast instead of waiting for prompts.