
Improving the security of your SSH private key files - martinkl
http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html
======
Tomdarkness
I keep my SSH key pairs on a smart card. It is very cheap to purchase a smart
card and card reader (~£25 for a gemalto reader & a gemalto .Net smardcard)
and if you're buying in medium to large quantities for a business the cost is
even less.

This has some major security and convenience advantages over keeping keys in a
file. Firstly, you can generate the keypair actually on the card so that the
only device that ever has, and will ever have, the private key is the
smartcard. Secondly, the key is secured by a pin and, by default, it will
block the card after 3 incorrect pin attempts and after 3 incorrect attempts
to unblock the card it will permanently erase the secure storage on the card.
Also you can easily make use of your keypair on multiple computers, even
untrusted machines, without compromising security. I keep my smartcard in my
wallet, so I always have access to it where ever I go.

Alternatively, if you don't want an actual card you can get smartcard-like
devices are are physically similar to a USB stick.

~~~
pooriaazimi
If someone gets hold if your smart card, they can enter a wrong pass phrase to
remove your private key, right? So, you have to have multiple of these smart
cards (that all share the same private key), some in your wallet, some in your
house and some in a bank or vault somewhere. Otherwise, you can lose access to
your private keys forever.

Am I right, or I'm missing something?

~~~
cnvogel
Depending on the cards and their configuration, you could generate the key
outside (say, on a trusted machine at home) and upload it to the card. If the
cards gets stolen, and you trust the security of the card to not leak the key,
you could just get yourself a new one and upload the old key again.

The other philosophy is to generate the key on the RSA card, and never allow
the card to export it. Then you consider the private key dispensable and will
have to update all systems to accept a new card's private key.

~~~
ams6110
_update all systems to accept a new card's private key._

That sort of a chicken/egg problem though, right? It assumes you've got
console or some other means of access that will take another credential.

~~~
Tomdarkness
I don't see a situation where you are unable to get console access as an
acceptable situation. You don't need to be using a smart card to require local
console access if things go bad. What about if the SSH server fails or someone
applies a bad firewall rule that prevents SSH access?

------
js2
Of course, this doesn't address what I consider the greatest weakness in using
ssh - distribution of host keys.

By design, ssh does not make use of certificates. So there is no way for ssh
to know upon connecting to a host for the first time whether the public key
presented by that host is authentic. After the first connection, ssh caches
the keys in ~/.ssh/known_hosts, and will then give you a big warning if the
key changes. I imagine when this happens many folks blindly delete the the
cached key and re-connect.

So you should be aware of the potential for MITM attacks to occur unless you
have some out-of-band mechanism for distributing or authenticating host keys.

Edit: huh, apparently ssh added support for certificates. "ssh-keygen supports
signing of keys to produce certificates that may be used for user or host
authentication." So now you just need to distribute your CA certificate
everywhere and you're golden.
[http://justanothergeek.chdir.org//2011/07/howto-
authenticate...](http://justanothergeek.chdir.org//2011/07/howto-authenticate-
ssh-server-through/)

~~~
mike-cardwell
You can put SSHFP records in the DNS. See "VerifyHostKeyDNS" in the SSH man
page. You'll also want DNSSEC set up of course.

~~~
peterwwillis
After you get a validating stub resolver, since your OS probably doesn't ship
with one by default.

~~~
mike-cardwell
Doesn't take long to do an "apt-get install unbound" and then modify your
network settings to use 127.0.0.1 as your resolver.

------
zobzu
While its actually an interesting post, the truth is: Don't copy your private
keys around. Keep em on your desktop/laptop.

Making your passphrase twice harder to crack is nice.. but whats 15 days
instead of 7? Making your passphrase 10000x harder to crack would also be
nice... but why care, if i have access to the file, i can just record your
keystrokes when you type the passphrase.

And that's why you can use an ssh-agent, and probably why OpenSSH doesn't care
much about changing the key format.

If you do not trust your laptop, the problem is still there. You can still
capture the keystrokes easily if you have access to the file, anyways.

I would suggest using something like a cryptostick or any openpgp smartcard
when the laptop is not trusted (actually, even if its relatively trusted I
would still recommend it!). This ensures the key is never transferred
somewhere it can be copied.

~~~
marcosdumay
> This ensures the key is never transferred somewhere it can be copied.

But it does not ensure that the computer will add another entry to the
authorized_keys file in the host as soon as you access it. Or install a
rootkit there with another kind of backdoor.

If you don't trust your computer, don't give it access to your servers.

~~~
zobzu
I'm not sure if I understand what you're saying, or if _you_ understand what
you're talking about to be honest.. ;-)

If you need to access a server you'll always need a computer. authorized_keys
are public keys only. it does not matter if other computers have your public
key. all it does is give you access.

the private key of your ssh key(s) give access to several servers, thats why
its the part that you want to protect. if one server has a rootkit, well, that
sucks. but if that rootkited server can access all the servers YOU can access,
you're screwed.

~~~
mentat
He's saying a latent program could hijack your established ssh connection to
add another public key corresponding with an attackers private key to get long
term access.

------
stormbrew
> openssl pkcs8 -topk8 -v2 des3 \

> -in test_rsa_key.old -passin 'pass:super secret passphrase' \

> -out test_rsa_key -passout 'pass:super secret passphrase'

Is there a way to do this without including the password on the command line?
Because somehow I don't think having your private key's password in your
.bash_history will improve the security of your key.

[edit] Oh I see, just don't specify and it'll ask. I get that he's doing this
with a sample key, but you just know someone's going to scan through this and
do that command on their real key.

~~~
rammark
If you put 'histcontrol=ignorespace' or 'histcontrol=ignoredups' in your
~/.bashrc file it will not record commands that begin with a space [1]. I
believe that 'ignoreboth' is the default on many Linux distros.

[1]: [http://www.linuxjournal.com/content/using-bash-history-
more-...](http://www.linuxjournal.com/content/using-bash-history-more-
efficiently-histcontrol)

~~~
joosters
You still shouldn't enter these kinds of commands on a multi-user machine,
because anyone running 'ps' will see the commandline arguments.

------
davidcuddeback
I couldn't help but notice that the original SSH key was encrypted with
AES-128-CBC and the "more secure" one mentions 3DES in the ASN.1 structure.
This makes me question if the "improved" SSH key really is more secure.

I'm not an encryption expert. Can someone else weigh in on this?

~~~
apawloski
The reason 3DES is avoided is because it is significantly slower than AES and
usually leads to generally poorer performance. Security-wise, it's fine to use
if you're willing to make these performance tradeoffs (eg, you might want it
for backwards compatibility with some ancient DES-friendly system).

~~~
tytso
The fact that 3DES is slower is actually an advantage if you are trying to
prevent against brute-force attacks. Given that we are encrypting binary data,
it's unlikely that knowledge of the plaintext (for example, knowing that it's
probably US-ASCII and so the 8th bit is probably always zero) is not going to
be available to the attacker. Other potential attacks, such as related
plaintext attacks, will also not be available to the attacker. Given that
brute force attacks are the most likely threat scenario, using a 3DES which is
slower is a reasonable choice.

~~~
jholman
Double-negative in your second sentence, and I think it's not what you meant.
I wouldn't be so pedantic, except that crypto is worth being pedantic about.

------
a3n

      ssh-keygen -t rsa -N 'boobooboo' -f test_rsa_key
    
      history
      ...
      964  ssh-keygen -t rsa -N 'boobooboo' -f test_rsa_key
    

Best if you let commands prompt you for a password, rather than putting them
on the command line for ps, history and everyone else to see.

~~~
gabipurcaru
Tip: you can prepend a space at the beginning of the command and it won't be
saved in the history (though I agree that letting the command prompt for a
password is better)

~~~
a3n
Excellent. Although that can be set to not do that. I've explicitly set it to
"ignoreboth" for so long that I'd forgotten why, so it seems new to me today.
:)

From man bash:

    
    
           HISTCONTROL
                  A colon-separated list of values controlling  how  commands  are
                  saved  on  the  history  list.   If  the list of values includes
                  ignorespace, lines which begin with a space  character  are  not
                  saved  in  the history list.  A value of ignoredups causes lines
                  matching the previous history entry to not be saved.  A value of
                  ignoreboth is shorthand for ignorespace and ignoredups.  A value
                  of erasedups causes all previous lines matching the current line
                  to  be  removed from the history list before that line is saved.
                  Any value not in the above list is ignored.  If  HISTCONTROL  is
                  unset,  or does not include a valid value, all lines read by the
                  shell parser are saved on the history list, subject to the value
                  of  HISTIGNORE.  The second and subsequent lines of a multi-line
                  compound command are not tested, and are added  to  the  history
                  regardless of the value of HISTCONTROL.

------
weichi
Very interesting article. But it makes we wonder ... if someone gets access to
your key file, that's nearly always going to be because they have access to
your login account, right? And at that point isn't the gig pretty much up?

In other words, how much additional security does password-protecting your
private key gain you?

~~~
lonnyk
If your HDD is stolen they can plug it into another computer and copy any file
they want.

~~~
claudius
They would get quite a few pseudorandom numbers of mine, aside from a self-
compiled Linux kernel. :-)

~~~
snuxoll
> aside from a self-compiled Linux kernel.

Likely sitting on an unencrypted /boot, waiting to be replaced by one with a
keylogger, am I right? Of course a sane person doesn't trust a system that's
been compromised before nuking it and reloading from a clean image.

~~~
claudius
There is unfortunately relatively little you can do to thwart such an attack,
apart from keeping your notebook with you at all/most times.

Though using a USB key for /boot might be an idea, it is a little less clunky
than a ThinkPad and since I suspend to RAM most of the time, it could even be
practical. Hm.

~~~
pak
Can't TPM be used for this? It could verify your /boot with keys external to
the disk itself. I'm not sure if somebody has actually built a solution that
uses it yet.

<https://en.wikipedia.org/wiki/Trusted_Platform_Module>

~~~
snuxoll
Sure it can, as can its evolution in the form of UEFI's Secure Boot, the
problem is everyone wants to label these as technologies to enable lock-in
instead of technologies to provide a trusted boot chain to ensure your system
isn't compromised.

------
oneofthose
There's Crypto-Stick [0], a security USB key with many interesting features.
It's essentially an OpenPGP card with some added features.

What excites me about their project is a very simple file-system based
interface they are planning to implement for their upcoming version. Plug the
key in, it looks like a regular USB key, put a file in a specific place, get
an encrypted/signed/whatever file from the file system from another place. No
driver or software required. I hope their project takes off and people start
buying these keys. The price is a little high right now (59,00 €) and it is
currently not available.

[0] <https://www.crypto-stick.com/>

------
cdjk
This is interesting - I've never thought to investigate how ssh stores keys.

For managing passphrases, I strongly recommend the program keychain:

<http://www.funtoo.org/Keychain>

It's a thin wrapper around ssh-agent, but ultimately means I only need to
enter my passphrase once.

The nifty feature is that you can add a command to your .login to clear your
passphrase, so it's safe to use on remote hosts - if someone else is able to
ssh in, they only get access to that host, not others that your ssh key allows
access to.

~~~
davidcuddeback
I just recently started using keychain as well. It's worth noting that it also
supports gpg-agent.

------
edwintorok
It is possible to store SSH private keys in gpg-agent, which uses the
openpgp-s2k3-sha1-aes-cbc algo to encrypt the key for storage.

s2k3 is an iterated-and-salted s2k algorithm from RFC2440, the protected
private key format is: [https://gitorious.org/gnupg-
org/gnupg/blobs/master/agent/key...](https://gitorious.org/gnupg-
org/gnupg/blobs/master/agent/keyformat.txt)

The number of iterations is at least 65536, whereas with pkcs8 openssl uses
2048 iterations by default.

More details on how to use SSH keys with GPG agent:
[http://budts.be/weblog/2012/08/ssh-authentication-with-
your-...](http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key)

------
rdl
I believe in having unique keys for each client device, then putting them in a
hashed authorized_hosts that you can treat as a unit.

That way, if someone steals my (FDE, managed) laptop or phone, I can revoke
just the credentials on that client device, not losing access to all my
servers.

Using tamper-resistant storage for the keys is a great idea; I wonder if
anyone has done TPM for ssh on windows, or just trousers on linux. Sadly for
Macs the only option is some kind of external USB token :( I kind of wish
someone made a bluetooth 4.0 le device which could hold keys and be used as a
smartcard/key device, maybe with trusted user I/O too. Maybe in a watch form
factor.

------
mixedbit
A crypto puzzle: Is it safe to encrypt several keys with the same passphrase?
Or is it possible to reveal the keys if the same passphrase was used to
encrypt them?

~~~
darkarmani
The key is encrypted using the IV as a salt and your passphrase. So even if
you encrypt the same key many times, the encrypted data will look completely
different unless the iv is the same.

------
iuguy
To be fair the DEK-Info IV should be different for each key generated, so
rainbow tables and other common precomputation attacks are pretty much out of
the question.

It's not as good as PBKDF2, but it's better than nothing and is probably why
stretching isn't used.

As for the argument about being susceptible to a dictionary attack, well if
you go to the trouble of using key-based auth then use a dictionary word
you're kind of asking for it really.

~~~
darkarmani
> To be fair the DEK-Info IV should be different for each key generated, so
> rainbow tables and other common precomputation attacks are pretty much out
> of the question.

That's valid; however, when you can compute 33.1B MD5 hashes a second, who
needs rainbow tables? <http://blog.zorinaq.com/?e=43>

Six and seven digit passphrases are easily brute-forced.

------
snowwrestler
My private SSH keys have passphrases of 19-20 random characters. I store them
in a KeePass database (AES encrypted) so that I can copy/paste. For keys on my
Mac, I've also allowed the KeyChain (Triple DES encrypted) to remember it so
that I don't have to copy/paste it every time.

I think this approach should be more secure than trying to set memorable
passphrases for all my keys. Thoughts?

~~~
fooyc
Where do you store the passphrase of your passphrase database ?

~~~
merijnv
I don't know about the grand parent, but personally I store that one in my
brain. It's about 32 (maybe more?) characters and quite complex, but it's the
only passphrase I need to use regularly so it's etched into my mind.

~~~
alyandon
You don't even need to have a pass phrase that long with KeePass. It allows
you to set the number of rounds of encryption to perform to make brute forcing
even short master passwords infeasible.

Of course, that assumes the master password is chosen such that it isn't
susceptible to your typical dictionary/hybrid-dictionary attacks.

------
petiepooo
Hey, if you're going to remove the old key, remove it securely: use srm!

------
atoponce
As far as I can tell, this only works with DSA and RSA, but not ECC keys
(~/.ssh/id_ecdsa). Thoughts?

~~~
atoponce
Ah. I am an id10t. Helps if I type the command correctly. Carry on.

------
marshallford
I use a 4096 bit length rsa key with a 200 something bit password. Am I safe?

------
drivebyacct2
Or just use a proper OpenPGP card.

