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?
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 :)
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.
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.
You can have a look at a similar question I asked about SSL private keys for web servers. Basically, there are three options:
- Protect the key with file system perms.
- Use a password protected key and enter the key manually in every restart.
- 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.)
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 :-)
~/.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.