Is it okay to use a SSH key with an empty passphrase?

Question

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?

Answer 1

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

Answer 2

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

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.