When using ssh-keygen:
What is the passphrase for?
Why is it optional?

What are the security implications of specifying (or not specifying) one?

Below is an excerpt taken from a shell session (some details may have been altered):

user@localhost:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /user/.ssh/id_rsa.
Your public key has been saved in /user/.ssh/id_rsa.pub.
The key fingerprint is:
60:8b:50:1e:0f:bc:5a:2a:13:1e:83:2b:d9:95:38:9e user@localhost
The key's randomart image is:
+---[RSA 2048]----+
|   .+            |
|   o.+           |
|. ...o+          |
|ooo.=o o         |
|.*oB. . S        |
|*.E              |
|.o               |
|                 |
|                 |
  • 2
    as a piece of advise I would tell you to try connecting to a SSH server with using a keyfile and with the -vvv option. this would illuminate how this works for you. – LvB Apr 13 '18 at 12:07
$ man ssh-keygen
It is possible to specify a passphrase when generating the
key; that passphrase will be used to encrypt the private
part of this file using 128-bit AES.

So this passphrase just encrypts the key locally. An attacker with access to your system will not be able to read the private key, because it's encrypted. (They could install a keylogger, though.) If your laptop is stolen for example, your ssh key might still be secure if you have a strong passphrase. Or even with a fairly weak passphrase (so long as it is not trivial), it will buy you some time to revoke the key and roll over to a new one, before the attackers can crack it.

It's optional because you can choose to accept the risk of having it not encrypted in storage. Or perhaps you have disk encryption enabled, which mitigates some of the same attacks (but not all, for example: malware can still steal the key, even with disk encryption; on the other hand, a stolen laptop is still secure unless stolen while running with the key in memory).

The server can require the use of both a public key and a password to log in. The security of this is different from using a password-encrypted public key. If you use an encrypted key, then:

  • you cannot change the password on the server side, you'll have to generate a new key;
  • someone might crack the key's password undetected, because they can do it offline (if the server requires a password, they have to ask the server "is aaaa correct? Is aaab correct?" etc.);
  • someone can crack the key much, much faster because it's an offline attack without network limitations; and
  • the server cannot use something like fail2ban to reject too many login attempts, because the cracking happens offline.
|improve this answer|||||
  • Doesn't using a password with a ssh key also prevent someone else using your key when connecting to a remote machine that already has your public key? I though the password was useful for the situation where a remote server only allows authenticated ssh access (ie. no user password logins), and as an added level of security requires a password when using the ssh key from the client. – cbcoutinho Apr 13 '18 at 11:24
  • @cbcoutinho I've edited my answer. Does that answer your question? – Luc Apr 13 '18 at 11:48
  • ja voor mij wel - bedankt! – cbcoutinho Apr 13 '18 at 12:14
  • Oh, I didn't see you weren't OP. Oops, I edited the question because I thought OP had an additional question :P – Luc Apr 13 '18 at 12:42

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.