When I first learned how to make ssh keys, the tutorials I read all stated that a good passphrase should be chosen. But recently, when setting up a daemon process that needs to ssh to another machine, I discovered that the only way (it seems) to have a key that I don't need to auth at every boot is to create a key with an empty passphrase. So my question is, what are the concerns with using a key with no passphrase?

7 Answers 7


A key with no passphrase is reliant upon nobody else being able to get at that key (who wouldn’t be able to get at the resources it gives access to anyway). So, if the key grants access to a machine next to it, and both machines have the same level of electronic and physical security, then it’s not really any big deal.

On the other hand, if your key is on a machine with poor security (perhaps it has many untrusted users, is easily physically accessible, or isn’t kept well up-to-date with its patching regime), then you probably don’t want to keep passphrase-less keys on there.

Ultimately, it’s down to confidence in your setup and weighing up the risks/costs of doing it — if you can be pretty confident that it’s not realistically easier for an attacker to gain access to the key than to the resource the key gives you access to, then you’re fine. If you don’t have that confidence, you should probably fix the reasons why :)

  • Only trusted people will have access to the machine with the keys, so I guess that answers my question. Thanks. May 18, 2010 at 13:40

another solution, enhancing security while making it easier on you, so you don't have to type your password all the time:

if you want to encrypt your private key, you can use ssh-agent on your workstation to 'cache' the unencrypted key. when you want to store your decrypted key, you run ssh-add ~/.ssh/id_rsa or whatever your private key is named. you will be prompted for the password, and the decrypted key will be available for your ssh connections until until you log out, kill ssh-agent or shutdown.

you can kill the stored keys with ssh-agent -k and you can assign a lifetime for the key to be in memory with ssh-agent -t [seconds] so for example; if you don't want to keep your key decrypted forever, but you want to do a lot of ssh-ing around your hosts, you can set the timeout to 5-10 minutes. so you don't have to continuously enter your key's password.

again, this all has to do with how confident you are of the security of your /workstation/, which, if you're the only one who has access to it, and you have a pretty secure local password, and you don't invite exploits and rootkits upon yourself, your passphrase-less private key is reasonably secure.

if you're like me, and you keep your private key on a thumb-drive, you are definitely going to want to encrypt that, even though it's just a private key (a separate one from which i use on my workstation, so if i lose my key, i can easily just remove the thumb-drive's public key from my server's ~/.ssh/authorized_keyslist, which also brings up an /excellent/ reason to add USEFUL comments to your public keys)

in your response to a previous answer, you said only people you trust have access to the machine with the keys. i just want to clarify that your private key does NOT need to be on the server you are connecting to, in case that is what you are doing. only your public key needs to be on the server, and that's a non-issue, which is why it's a 'public' key.

oh, i forgot to mention; i launch ssh-agent when i start X, otherwise the de-crypted keys i store with ssh-add aren't retained through different xterm sessions, and i have to re-enter the password every time i close the xterm i launched ssh-add in. in my ~/.xinitrc file, i have:

if [ -x /usr/bin/ssh-agent ]; then
   eval $(/usr/bin/ssh-agent)

i have the call to ssh-agent wrapped in eval because ssh-agent returns some environment variables that need to be set when it runs, and run from ~/.xinitrc, the environment variables are constant throughout the X session.

  • Yeah - I know I only need to upload the public key. It's just that I'm connecting one server to another, which is why I mentioned that. But thank you for writing out this clear and thoughtful answer. May 18, 2010 at 21:41
  • well, if you use ssh-agent and use ssh -A -i privkey user@host it will allow ssh agent forwarding, which would allow you to access a server from the initial server, without placing your private key on the first server. ssh chaining is not recommended, even without ssh key forwarding enabled, and ssh -A has its own security concerns. there's no reason the key on the server can't be encrypted, while the key on your workstation is passphrase-less.
    – cpbills
    May 18, 2010 at 21:52

You can have a look at a similar question I asked about SSL private keys for web servers. Basically, there are three options:

  1. Protect the key with file system perms.
  2. Use a password protected key and enter the key manually in every restart.
  3. Use a password protected key and store the key in the filesystem to automate restart.

Each of them is flawed, so it all depends on what do you fear most.


For automated access, which as you say requires passphrase-less keys, I always use the extra options of authorized_keys (see sshd(8)) to limit the command that can be run.

Usually I provide a carefully written script at the remote end, which does exactly the job (or jobs - it can look at parameters) that I want to be permitted.

Then I also lock it down to the IP addresses that can connect in with that key (not 100% foolproof, but fine with the command restriction as well.)

  • 1
    Excellent point - if you do find it necessary to use unprotected keys, the best thing you can do is lock it down!
    – MikeyB
    May 18, 2010 at 17:53
  • Is the locking down feature used inside the key? Or it's set up on server? Jul 13, 2021 at 10:20
  • see specifically the from option, of authorized_keys.
    – jrg
    Aug 5, 2021 at 13:48

As long as no-one other than you has access to the key, you do not require a passphrase. In fact, you cannot use a passphrase on keys used by automated software.


If you want to use ssh to do any kind of automated procedure - I'm thinking specifically of Nagios checks - then you probably wouldn't want to use a passphrase.

In this situation you probably wouldn't be using this outside of a LAN, and you would have the key stored securely on the server doing the procedure.

Most tutorials discussing SSH will be anticipating a person logging in from an external network, possibly from an unsecure computer, in which case the advice is sound.

Basically, unless you know there is a good reason not to, create a passphrase. Being too lazy to type in your password every time might be a good enough reason for you :-)

  • Even if they log in from an external network, how does that make a difference? Only the security of the client computer matters, the passphrase is handled on the client side, right?
    – njsg
    Jun 2, 2013 at 12:43
  • Until your client laptop gets stolen and used to breach your perimeter before anyone has a chance to revoke the SSH key. A passphrase on the key would give you more time to revoke the keys.
    – dunxd
    Jun 3, 2013 at 8:30
  • So, like I said, "Only the security of the client computer matters".
    – njsg
    Jun 5, 2013 at 19:04

ssh certificates

An ~/.ssh/authorized_keys file grants access to an SSH server with grant option because in the default setting that file is owned by the user, so that user can add friend's public keys to share the access. Also it is at the discretion of the user to implement options like @jrg mentioned. If the user actually has a passphrase, or not, is not known by sshd. So no matter your opinion on the safety of using passphrases, there will always be people that don't use them, or remove them.

An alternative is a signing process with ssh-keygen that creates a certificate authority key-pair on a secured system independent of your servers and ssh clients. This is just an ssh key-pair, but with a passphrase, a strong algorithm and brute-force protection:

ssh-keygen -t ed25519 -a 500 -f ~/.ssh/trusted-user-ca-keys

The public key of the CA is installed on the ssh servers. Both AuthorizedKeysFile and PasswordAuthentication are disabled:

TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pub
PasswordAuthentication no
AuthorizedKeysFile /dev/null

The only way to access the ssh server is by using a signed public key. Anyone that needs access should apply for access by sending their public key to the CA. In return they recieve a tamperproof certificate that can include options as described in man ssh-keygen, and for example a validity of one week:

ssh-keygen -s ~/.ssh/ca_ssh -I user -O no-port-forwarding -O no-pty -V +1w user.pub
  • You don't need to manage authorized_keys files on your servers anymore.
  • Users cannot tamper with their authorized_keys file.
  • You can rotate permissions with temporary access.
  • You can lock options.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.