WardtermSSH client
EN
Download

SSH password manager: how to store SSH passwords securely

Where you can, replace SSH passwords with keys, because a key never crosses the network. For passwords you must keep, store them in the system keychain or an encrypted vault, never in scripts, shell history or sshpass -p, which shows the password to every process on the machine. If you need sshpass, read the password from the keychain and pass it with sshpass -e.

Updated . Run on macOS 27 with OpenSSH 10.3: ssh-keygen and ssh-add --apple-use-keychain.

Keys first, passwords second

The best SSH password is the one you no longer need. With a key, the server checks a signature and no secret crosses the network, so a stolen copy of your typing or a fake server gets nothing useful. Create a key and install it on the server:

ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

Then test it and turn password login off on the server, as described in how to disable SSH password login. The full key setup is in how to generate an Ed25519 SSH key.

Passwords remain for real reasons: devices that only accept them, accounts you do not control, sudo on the server, and the first login before a key is installed. Those are the ones to store well.

Why sshpass -p is a bad idea

sshpass types a password into ssh for you. Its most common form is also the weakest:

sshpass -p 'S3cret!' ssh deploy@203.0.113.10

The password is part of the command line. While the command runs, any user on the machine can read it with ps, and it is saved in your shell history. Its own manual calls -p the least secure option. The other two forms are better:

sshpass -f ~/.ssh/web.pass ssh deploy@203.0.113.10
SSHPASS='S3cret!' sshpass -e ssh deploy@203.0.113.10

-f reads the first line of a file, which must be readable only by you (chmod 600). -e reads the SSHPASS variable, which is still visible to processes that run as you. Two more traps: sshpass cannot answer the host key question, so on a new server it fails with exit code 6, and people then add StrictHostKeyChecking=no, which removes the protection against a fake server. Accept the host key once by hand instead.

Keep passwords in the system keychain

Instead of a file, let the operating system hold the password. On a Mac, save it in the login keychain. With -w last and no value, the command asks for the password, so it never appears on the command line:

security add-generic-password -a deploy -s ssh-web -w

Read it back only for the command that needs it:

SSHPASS="$(security find-generic-password -a deploy -s ssh-web -w)" sshpass -e ssh deploy@web

On Linux desktops, secret-tool does the same with the GNOME keyring or KWallet:

secret-tool store --label='ssh web' service ssh host web user deploy
secret-tool lookup service ssh host web user deploy

The keychain is unlocked when you log in, and it keeps the password encrypted on disk. Any program running as you can still ask for it, which is why the first answer stays a key.

Store key passphrases the same way

A key should have a passphrase, and the keychain can remember it so you type it once. On a Mac:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519
Host *
  UseKeychain yes
  AddKeysToAgent yes

The details, including what happens after a restart, are in how to use ssh-agent with the macOS Keychain. On Linux, ssh-agent or the desktop keyring plays the same role.

What an SSH password manager should do

A general password manager stores the secret. For SSH, a few more things matter:

  • Encryption on your device, with a password or the system unlock to open it. If it syncs, the server should only see encrypted data. The end-to-end encrypted vault guide lists the questions to ask.
  • One login for many servers. A user with its password or key, saved once and linked to each server, so a change happens in one place.
  • Keys and passwords together, so a server that moves to a key keeps the same entry.
  • Typing only when asked. The password goes to the prompt that wants it, not to the clipboard, not to a file.

An SSH key manager with an encrypted vault covers these in one place, next to the servers themselves.

Mistakes to avoid

  • Passwords in scripts or in a repository. They end up in backups, logs and other people's clones.
  • Passwords in shell history. In bash, set HISTCONTROL=ignorespace and start a command with a space to keep it out. In zsh, use setopt HIST_IGNORE_SPACE.
  • One shared root password for a team. Give each person an account and a key, and use sudo.
  • The same password everywhere. One breach then opens every server.
  • Passwords in the clipboard. Clipboard managers and synced clipboards keep a copy.

Questions

Is it safe to store SSH passwords in a password manager?

Yes, if the manager encrypts its data on your device and asks for a password or the system unlock before it opens. It is much safer than a text file, a script or a note. A key is still better than any stored password.

Why is sshpass -p unsafe?

The password is part of the command line, so anyone on the machine can see it with ps while the command runs, and it lands in your shell history. sshpass -e or -f avoids both.

Can I put an SSH password in ~/.ssh/config?

No. OpenSSH has no password option in its config file, on purpose. The file can point to a key with IdentityFile, and the key passphrase can live in the system keychain.

Should I use the same password on several servers?

No. One leaked server then opens all the others. If you must use passwords, use a different one per server and keep them in a manager.

Sources

More in Encrypted vaults

All guides