Most people meet sshpass through a single example, but the tool has several ways to receive a password, and choosing among them matters. The option you pick decides whether the password appears in a process listing, sits in a file, lives in an environment variable, or arrives through a file descriptor. Each method has a different security profile, and understanding the four main options is the difference between using sshpass casually and using it responsibly.
The -p Option: Password on the Command Line
The -p option takes the password directly as an argument. It is the easiest method to demonstrate and the easiest to get wrong. The problem is that command-line arguments are visible to other users on the same machine through the process table while the command runs. On a shared system, that exposure is real, even if it lasts only a few seconds. For that reason, the tool’s own documentation discourages -p for anything beyond quick, private testing. If you use it at all, use it on a machine you control, for a low-value account, and never in a script that others can read.
There is a second problem with -p: the password ends up in shell history unless you take care to prevent it. A command typed interactively is usually saved, and a password in history is a credential waiting to be found. Disabling history for a session, or running the command in a way that avoids recording it, reduces that risk, but it is easy to forget. These are the reasons experienced users treat -p as a teaching example rather than a production method.
The -f Option: Password from a File
The -f option reads the password from a file, using only the first line. This is a meaningful improvement, because the password no longer appears in the process list or in shell history. The security of the method now depends on the security of the file. The file should be owned by the automation account, readable only by that account, and stored outside any shared directory. Permissions such as read-only for the owner are the minimum; the file should also be excluded from backups that are widely accessible and from version control.
A file-based password is still a password at rest, so it should be rotated on a schedule, and the account it unlocks should have the smallest permissions that let the job succeed. If the file is ever copied or the account is ever compromised, changing the password limits the damage. Some teams generate a dedicated automation account whose password is used only by sshpass, so that rotating it affects nothing else.
The -e Option: Password from an Environment Variable
The -e option reads the password from an environment variable named SSHPASS. This method is popular in continuous integration and container setups, where the platform injects secrets as environment variables. The password does not appear on the command line, and it does not need a file on disk. However, environment variables are not secret by magic: they can be visible to child processes and, in some setups, to debugging tools. They should be set by the scheduler or secrets manager just before the job runs, and they should not be printed in logs.
The practical advantage of -e is that it fits naturally into modern automation. A pipeline can store the password in its secret store, expose it as an environment variable for one job, and discard it when the job ends. Combined with a short-lived account, this is one of the more defensible ways to use sshpass. The official reference at sshpass.com documents this option alongside the others, which makes it easy to compare them side by side.
The -d Option: Password from a File Descriptor
The -d option is the most flexible and the least understood. It reads the password from a numbered file descriptor, which means a script can pass the password through a pipe or a redirected descriptor without ever writing it to disk or placing it on the command line. This gives the script author full control over where the password comes from and who can see it. It is more work to set up than the other options, because the script must manage descriptors correctly, but for careful automation it offers the best balance of convenience and control.
A Practical Comparison
If you rank the options by exposure, -p exposes the most, -f and -e expose less, and -d exposes the least, assuming each is used correctly. No option makes a password safe in an absolute sense. A password that a script can read is a password that can be stolen by anyone who can read the script’s inputs. The goal is to shrink the window of exposure and to limit what the password can do, not to pretend the risk has vanished.
Other Useful Options
Beyond password sources, sshpass offers a verbose mode that explains what it is doing, which is invaluable when a connection fails and you need to know whether the password prompt appeared at all. It also lets you set a prompt pattern, which helps when a server uses a non-standard prompt. These options do not change security directly, but they make debugging far easier, and a tool you can debug is a tool you can trust.
Choosing the Right Option
For a quick test on your own machine, -p is acceptable. For a scheduled job, prefer -f with a protected file or -e with a platform-managed secret. For a script that must be especially careful, use -d. In every case, pair the choice with a limited account, regular rotation, and a plan to move to key-based authentication. The option you choose is not a detail; it is the main security decision in the whole setup.
Conclusion
sshpass gives you four ways to supply a password, and each trades convenience against exposure. Learning what -p, -f, -e, and -d actually do lets you pick the least exposed method your situation allows. That knowledge, more than any single command, is what separates a careless automation from a responsible one.
