How to Pass Your Username and Password in an SSH Command

You can pass SSH credentials in the command line, but it creates security risks you should understand first

SSH commands normally prompt you to enter your password after you type the command. You can skip that prompt by embedding your username and password directly in the command — the syntax is ssh username@hostname for the username, and tools like sshpass or expect to handle the password. However, this method stores your password in plain text in your command history, shell scripts, and process listings, where anyone with access to your machine can read it.

Most security professionals recommend using SSH keys instead, which accomplish the same goal without exposing your password. SSH keys are a public-private key pair that prove your identity without ever transmitting a password. If you cannot use keys, understanding the trade-offs of password embedding helps you choose the least risky approach.

Key Takeaways

The username goes directly in the SSH command as ssh username@hostname, but the password requires a separate tool like sshpass because SSH does not accept a password flag.
Using sshpass or expect stores your password in your shell history and any script file, making it visible to anyone who gains access to your account.
SSH keys (public and private key pairs) let you log in without typing a password at all and do not expose credentials in command history.
If you must use a password in a script, sshpass with the -f flag (reading from a file) is safer than the -p flag (command-line argument).

Why SSH does not accept a password flag directly

SSH was designed to prompt you for your password interactively — it reads the password from your terminal, not from the command line. This design choice exists because command-line arguments are visible to other processes on your machine. If you typed ssh -p mypassword username@hostname, anyone running ps aux could see your password in the process list.

SSH deliberately avoids this by refusing password flags altogether. You cannot pass a password the way you might pass other options. This is a security feature, not a limitation you can easily work around. The restriction forces you to either use interactive prompts, SSH keys, or external tools that handle the password more carefully than the command line would.

Using sshpass to embed a password in a command

The tool sshpass solves this by reading your password from a separate source — either a command-line argument, an environment variable, or a file — and feeding it to SSH as if you had typed it. The basic syntax is:

sshpass -p 'your_password' ssh username@hostname

You can also store the password in a file and reference it instead:

sshpass -f password_file.txt ssh username@hostname

Or read it from an environment variable:

export SSHPASS='your_password'sshpass -e ssh username@hostname

The file method is slightly safer than the command-line method because the password does not appear in your shell history, but it still requires the file to exist on disk with readable permissions. If you use this approach, set the file permissions to 600 (readable only by you) with chmod 600 password_file.txt. This prevents other users on the same machine from reading the file.

What happens to your password when you use sshpass

When you run sshpass with a password on the command line, that password is visible in three places: your shell history file (usually ~/.bash_history or ~/.zsh_history), the process list while the command runs, and any script file where you embed the command. Anyone with access to your account or your machine can read these locations.

If you use sshpass in a script that other people can read, they can extract the password and use it themselves. If you use it on a shared server, other users can see the password in the process list for the few seconds the command runs. Even if you delete the script later, the password may remain in your shell history until that history file is overwritten. Using the -f flag (file-based password) or -e flag (environment variable) reduces but does not eliminate this exposure.

Using SSH keys instead of passwords

SSH keys are a public-private key pair. Your private key stays on your local machine, and your public key goes on the remote server. When you connect, SSH proves you own the private key without ever sending the key itself or a password over the network. This is more find than passwords and does not require you to embed credentials in commands or scripts.

To set up SSH keys, generate a key pair on your local machine with:

ssh-keygen -t rsa -b 4096

This creates two files: ~/.ssh/id_rsa (your private key) and ~/.ssh/id_rsa.pub (your public key). Copy the contents of id_rsa.pub to the remote server's ~/.ssh/authorized_keys file. After that, you can log in with ssh username@hostname and SSH will use your key automatically — no password prompt, no embedded credentials.

If you want to automate SSH commands in scripts, SSH keys are the standard approach. The script can run ssh username@hostname 'command' without any password or sshpass wrapper, because the key authentication happens silently in the background. This is why most organizations use keys for server automation rather than passwords.

Using expect for more complex password scenarios

The tool expect is a scripting language designed to automate interactive programs. It can handle SSH logins where the server asks for a password, and also handle follow-up prompts. A basic expect script looks like:

#!/usr/bin/expect spawn ssh username@hostname expect "password:" send "your_password\r" interact

The spawn command starts the SSH process, expect waits for the password prompt, send types the password, and interact hands control back to you. Expect is more flexible than sshpass because it can respond to multiple prompts, but it carries the same security risk: your password is stored in the script file in plain text. Expect is useful when the remote server requires additional authentication steps beyond the initial password, or when you need to run commands after login and respond to prompts. For straightforward password-only authentication, sshpass is simpler.

Security trade-offs when you must use passwords

If your situation requires embedding a password — because you cannot use SSH keys, the remote server does not support them, or your organization requires password authentication — here is how to minimize exposure:

Store the password in a file with restricted permissions (chmod 600), not in the command line itself. Use sshpass with the -f flag to read from that file. Keep the file on your local machine only, not on shared servers or in version control. If the password changes, update the file when ready. Document why you are using this method so that future maintainers understand the trade-off and can migrate to keys when possible.

Even with these precautions, anyone with root access to your machine or read access to your home directory can still extract the password. This is why SSH keys are preferred: they do not require storing a secret that grants access to another machine, and they cannot be used to log in to other systems where you might have reused the same password.

Frequently Asked Questions

Can I pass a password directly in the SSH command without sshpass?

No. SSH deliberately does not accept a password flag because command-line arguments are visible to other processes. You must use a tool like sshpass, expect, or a script that reads the password from a file or environment variable.

Is sshpass safe to use in production scripts?

It is safer than embedding the password on the command line, but less safe than SSH keys. If you use sshpass, store the password in a file with 600 permissions and document why you cannot use keys instead. SSH keys are the standard for production automation.

What if I generate an SSH key but the remote server only accepts passwords?

Ask the server administrator to enable public key authentication. Most modern servers support it. If they refuse, that is a security policy decision you should escalate — password-only authentication is weaker than key-based authentication, especially for automated access.

Will my password show up in shell history if I use sshpass?

Yes, if you pass the password on the command line with -p. To avoid this, use -f to read from a file or -e to read from an environment variable. You can also disable history for a single command by prefixing it with a space (in bash with HISTCONTROL=ignorespace), but this is unreliable.

Can I use SSH keys and still automate logins without typing anything?

Yes. Once you add your public key to the remote server's authorized_keys file, SSH uses the key automatically. You can run ssh username@hostname 'your command' in scripts with no password prompt and no credential exposure.

This guide is for general information only and is not medical, financial, legal, or other professional advice. For decisions specific to your situation, consult a qualified professional. See our Editorial Policy.