Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 23 down vote accepted

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 :)

share|improve this answer
Only trusted people will have access to the machine with the keys, so I guess that answers my question. Thanks. – mozillalives May 18 '10 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.

share|improve this answer
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. – mozillalives May 18 '10 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 '10 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.

share|improve this answer

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.)

share|improve this answer
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 '10 at 17:53

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.

share|improve this answer

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 :-)

share|improve this answer
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 '13 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 '13 at 8:30
So, like I said, "Only the security of the client computer matters". – njsg Jun 5 '13 at 19:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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