11 ms·

Improving the security of your SSH private key files

330 points by martinkl 13y ago

stormbrew 13y ago
> 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.
- X-Istence 13y ago
  He did in the last example that shows how to do this on an actual file ...
- rammark 13y ago
  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-efficiently-histcontrol http://www.linuxjournal.com/content/using-bash-history-more-...
  - joosters 13y ago
    You still shouldn't enter these kinds of commands on a multi-user machine, because anyone running 'ps' will see the commandline arguments.
- makr17 13y ago
  $ export HISTFILE=/dev/null
  - Nux 13y ago
    You want: unset HISTFILE
    - yew 13y ago
      Don't do that in your .bash_profile unless you run login shells on all of your terminals! Setting HISTFILE propagates that setting to child shells - unsetting HISFILE does not.
    - dsl 13y ago
      Undefined = Default
- jlgaddis 13y ago
  Leave out -passin and -passout. Provide your current passphrase at the first prompt ("Enter passphrase for <infile>:") and your new passphrase at the second and third prompts ("Enter Encryption Password:" and "Verifying - Enter Encryption Password:"). You may use the same or a different passphrase on your new key.
- vacri 13y ago
  To avoid a command showing up in history, start the whole command with a space and the line won't be recorded to history. Or if that horse has already bolted, you can use the 'history' command to find the line number and then delete it. Of course, most things that require passwords will request that you manually enter one if you leave the arg off.
- stormbrew 13y ago
  To clarify, my point is that a blog post about improving your security should not have an easily cut-and-pasteable reference for substantially decreasing your security, even if it's intended to be used on a dummy file.
a3n 13y ago
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.
- q_revert 13y ago
  i'm not sure if it works in all shells, but at least in zsh/bash doing $ echo "this will not be saved in history" as opposed to $echo "this will be saved in history" can be useful
  - pooriaazimi 13y ago
    AFAIK, in bash/zsh you have to do export HISTCONTROL=ignoredups:ignorespace in .bashrc or .bash_profile for the above trick to work. fish, OTOH, seems to do this by default.
- gabipurcaru 13y ago
  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 13y ago
    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.
deleted 13y ago
[deleted]
davidcuddeback 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.
  - davidcuddeback 13y ago
    Thanks for the replies. I'm certainly no expert on this stuff. A few years ago, I implemented DES as a learning exercise [1]. I recall reading something at the time about security concerns with DES. That was several years ago, so I'm probably mis-remembering. Wikipedia vaguely refers to concerns about security being a motivation for AES, but doesn't explain what those concerns were [2]. [1] https://github.com/dcuddeback/des_crack https://github.com/dcuddeback/des_crack [2] https://en.wikipedia.org/wiki/Data_Encryption_Standard#Replacement_algorithms https://en.wikipedia.org/wiki/Data_Encryption_Standard#Repla...
weichi 13y ago
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 13y ago
  If your HDD is stolen they can plug it into another computer and copy any file they want.
  - claudius 13y ago
    They would get quite a few pseudorandom numbers of mine, aside from a self-compiled Linux kernel. :-)
    - snuxoll 13y ago
      > 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 13y ago
        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 13y ago
        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 https://en.wikipedia.org/wiki/Trusted_Platform_Module
iuguy 13y ago
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 13y ago
  > 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 http://blog.zorinaq.com/?e=43 Six and seven digit passphrases are easily brute-forced.
snowwrestler 13y ago
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 13y ago
  Where do you store the passphrase of your passphrase database ?
  - merijnv 13y ago
    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 13y ago
      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.
    - snowwrestler 13y ago
      Same here. I also require a key file for KeePass. It's not encrypted, but it's just one more thing a bad guy would have to acquire to get in.
    - vacri 13y ago
      You might still want to write that one down somewhere and store it somewhere safe (and probably hard to get to). A friend of mine recently forgot his PIN. A four-number code used regularly for over ten years. Just gone like that. Your memory is a SPOF, and while generally robust for this sort of thing, it's not bulletproof.
zobzu 13y ago
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 13y ago
  > 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 13y ago
    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 13y ago
      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.
js2 13y ago
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-ssh-server-through/ http://justanothergeek.chdir.org//2011/07/howto-authenticate...
- mike-cardwell 13y ago
  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 13y ago
    After you get a validating stub resolver, since your OS probably doesn't ship with one by default.
    - mike-cardwell 13y ago
      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.
  - rscale 13y ago
    And if you're using a DNS service that doesn't support SSHFP records, you can generate and distribute a base known_hosts file with your favorite configuration management solution.
cdjk 13y ago
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 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 13y ago
  I just recently started using keychain as well. It's worth noting that it also supports gpg-agent.
Tomdarkness 13y ago
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.
- SpikedCola 13y ago
  I'm quite interested in this, as I have some old smartcard readers around from the days of Nagra/Nagra2. Care to share any more details?
  - cdjk 13y ago
    The smartcard needs to support openpgp smart cards. You then create an RSA gpg key with three subkeys - signing, encryption, and authentication. You'll have to enable the advanced key-creation mode for the last one. That authentication subkey then becomes your ssh key. There are plenty of tutorials online, but none are particularly good. I've been meaning to regenerate my keys, so maybe I'll take notes and try to write up a good one. Here are a few links: http://wiki.debian.org/Smartcards/OpenPGP http://wiki.debian.org/Smartcards/OpenPGP http://www.gnupg.org/howtos/card-howto/en/smartcard-howto.html http://www.gnupg.org/howtos/card-howto/en/smartcard-howto.ht... https://www.crypto-stick.com/ https://www.crypto-stick.com/ The last one is interesting - it's a smart card reader and integrated smart card built into a usb stick.
  - Tomdarkness 13y ago
    Most likely will depend on what smartcard you get but here is how I do it with my Gemalto card: I use the Minidriver manager tool from: http://www.gemalto.com/products/dotnet_card/resources/development.html http://www.gemalto.com/products/dotnet_card/resources/develo... although you could use something like pkcs11-tool. Generating a RSA keypair is as simple as right clicking on an empty container, selecting OBKG Container and filling this out: http://i.imgur.com/uMY53OD.png http://i.imgur.com/uMY53OD.png It will display the public key but it is in hex and uses Microsoft's PublicKeyBlob structure. OpenSSL will convert this to PEM for you though, which is what you want for SSH authentication. Something like: openssl rsa -pubin -inform MSPUBLICKEYBLOB -in "C:\path\to\my\publickey" -outform PEM -out "C:\path\to\my\publickey.pem" Open this new file in a text editor and get rid of the begin and end public key lines and just smack it all on one line with "ssh-rsa " (note the space) in front of it. You can then add this to your server's authorized_keys file. OpenSSH can use a pkcs11 library for authentication (-I option), which is also avaliable from Gemalto's website (these are generally specific to the smartcard), and on Windows there is a version of PuTTY called PuTTY SC that will also let you use the pkcs11 library.
mixedbit 13y ago
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 13y ago
  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.
- wiml 13y ago
  I think that this is not a risk (between the PBKDF2 salt and the IV of the underlying cipher). IANAprofessionalcryptographer, however.
petiepooo 13y ago
Hey, if you're going to remove the old key, remove it securely: use srm!
drivebyacct2 13y ago
Or just use a proper OpenPGP card.
edwintorok 13y ago
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/keyformat.txt https://gitorious.org/gnupg-org/gnupg/blobs/master/agent/key... 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-pgp-key http://budts.be/weblog/2012/08/ssh-authentication-with-your-...
oneofthose 13y ago
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/ https://www.crypto-stick.com/
rdl 13y ago
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.
atoponce 13y ago
As far as I can tell, this only works with DSA and RSA, but not ECC keys (~/.ssh/id_ecdsa). Thoughts?
- atoponce 13y ago
  Ah. I am an id10t. Helps if I type the command correctly. Carry on.
marshallford 13y ago
I use a 4096 bit length rsa key with a 200 something bit password. Am I safe?

330 points by martinkl 13y ago

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

X-Istence 13y ago
He did in the last example that shows how to do this on an actual file ...
rammark 13y ago
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-efficiently-histcontrol http://www.linuxjournal.com/content/using-bash-history-more-...
- joosters 13y ago
  You still shouldn't enter these kinds of commands on a multi-user machine, because anyone running 'ps' will see the commandline arguments.
makr17 13y ago
$ export HISTFILE=/dev/null
- Nux 13y ago
  You want: unset HISTFILE
  - yew 13y ago
    Don't do that in your .bash_profile unless you run login shells on all of your terminals! Setting HISTFILE propagates that setting to child shells - unsetting HISFILE does not.
  - dsl 13y ago
    Undefined = Default
jlgaddis 13y ago
Leave out -passin and -passout. Provide your current passphrase at the first prompt ("Enter passphrase for <infile>:") and your new passphrase at the second and third prompts ("Enter Encryption Password:" and "Verifying - Enter Encryption Password:"). You may use the same or a different passphrase on your new key.
vacri 13y ago
To avoid a command showing up in history, start the whole command with a space and the line won't be recorded to history. Or if that horse has already bolted, you can use the 'history' command to find the line number and then delete it. Of course, most things that require passwords will request that you manually enter one if you leave the arg off.
stormbrew 13y ago
To clarify, my point is that a blog post about improving your security should not have an easily cut-and-pasteable reference for substantially decreasing your security, even if it's intended to be used on a dummy file.

a3n 13y ago

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.

q_revert 13y ago
i'm not sure if it works in all shells, but at least in zsh/bash doing $ echo "this will not be saved in history" as opposed to $echo "this will be saved in history" can be useful
- pooriaazimi 13y ago
  AFAIK, in bash/zsh you have to do export HISTCONTROL=ignoredups:ignorespace in .bashrc or .bash_profile for the above trick to work. fish, OTOH, seems to do this by default.
gabipurcaru 13y ago
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 13y ago
  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.

deleted 13y ago

[deleted]

davidcuddeback 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.
- davidcuddeback 13y ago
  Thanks for the replies. I'm certainly no expert on this stuff. A few years ago, I implemented DES as a learning exercise [1]. I recall reading something at the time about security concerns with DES. That was several years ago, so I'm probably mis-remembering. Wikipedia vaguely refers to concerns about security being a motivation for AES, but doesn't explain what those concerns were [2]. [1] https://github.com/dcuddeback/des_crack https://github.com/dcuddeback/des_crack [2] https://en.wikipedia.org/wiki/Data_Encryption_Standard#Replacement_algorithms https://en.wikipedia.org/wiki/Data_Encryption_Standard#Repla...

weichi 13y ago

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 13y ago
If your HDD is stolen they can plug it into another computer and copy any file they want.
- claudius 13y ago
  They would get quite a few pseudorandom numbers of mine, aside from a self-compiled Linux kernel. :-)
  - snuxoll 13y ago
    > 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 13y ago
      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 13y ago
        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 https://en.wikipedia.org/wiki/Trusted_Platform_Module

iuguy 13y ago

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 13y ago
> 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 http://blog.zorinaq.com/?e=43 Six and seven digit passphrases are easily brute-forced.

snowwrestler 13y ago

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 13y ago
Where do you store the passphrase of your passphrase database ?
- merijnv 13y ago
  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 13y ago
    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.
  - snowwrestler 13y ago
    Same here. I also require a key file for KeePass. It's not encrypted, but it's just one more thing a bad guy would have to acquire to get in.
  - vacri 13y ago
    You might still want to write that one down somewhere and store it somewhere safe (and probably hard to get to). A friend of mine recently forgot his PIN. A four-number code used regularly for over ten years. Just gone like that. Your memory is a SPOF, and while generally robust for this sort of thing, it's not bulletproof.

zobzu 13y ago

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 13y ago
> 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 13y ago
  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 13y ago
    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.

js2 13y ago

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-ssh-server-through/ http://justanothergeek.chdir.org//2011/07/howto-authenticate...

mike-cardwell 13y ago
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 13y ago
  After you get a validating stub resolver, since your OS probably doesn't ship with one by default.
  - mike-cardwell 13y ago
    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.
- rscale 13y ago
  And if you're using a DNS service that doesn't support SSHFP records, you can generate and distribute a base known_hosts file with your favorite configuration management solution.

cdjk 13y ago

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 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 13y ago
I just recently started using keychain as well. It's worth noting that it also supports gpg-agent.

Tomdarkness 13y ago

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.

SpikedCola 13y ago
I'm quite interested in this, as I have some old smartcard readers around from the days of Nagra/Nagra2. Care to share any more details?
- cdjk 13y ago
  The smartcard needs to support openpgp smart cards. You then create an RSA gpg key with three subkeys - signing, encryption, and authentication. You'll have to enable the advanced key-creation mode for the last one. That authentication subkey then becomes your ssh key. There are plenty of tutorials online, but none are particularly good. I've been meaning to regenerate my keys, so maybe I'll take notes and try to write up a good one. Here are a few links: http://wiki.debian.org/Smartcards/OpenPGP http://wiki.debian.org/Smartcards/OpenPGP http://www.gnupg.org/howtos/card-howto/en/smartcard-howto.html http://www.gnupg.org/howtos/card-howto/en/smartcard-howto.ht... https://www.crypto-stick.com/ https://www.crypto-stick.com/ The last one is interesting - it's a smart card reader and integrated smart card built into a usb stick.
- Tomdarkness 13y ago
  Most likely will depend on what smartcard you get but here is how I do it with my Gemalto card: I use the Minidriver manager tool from: http://www.gemalto.com/products/dotnet_card/resources/development.html http://www.gemalto.com/products/dotnet_card/resources/develo... although you could use something like pkcs11-tool. Generating a RSA keypair is as simple as right clicking on an empty container, selecting OBKG Container and filling this out: http://i.imgur.com/uMY53OD.png http://i.imgur.com/uMY53OD.png It will display the public key but it is in hex and uses Microsoft's PublicKeyBlob structure. OpenSSL will convert this to PEM for you though, which is what you want for SSH authentication. Something like: openssl rsa -pubin -inform MSPUBLICKEYBLOB -in "C:\path\to\my\publickey" -outform PEM -out "C:\path\to\my\publickey.pem" Open this new file in a text editor and get rid of the begin and end public key lines and just smack it all on one line with "ssh-rsa " (note the space) in front of it. You can then add this to your server's authorized_keys file. OpenSSH can use a pkcs11 library for authentication (-I option), which is also avaliable from Gemalto's website (these are generally specific to the smartcard), and on Windows there is a version of PuTTY called PuTTY SC that will also let you use the pkcs11 library.

mixedbit 13y ago

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 13y ago
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.
wiml 13y ago
I think that this is not a risk (between the PBKDF2 salt and the IV of the underlying cipher). IANAprofessionalcryptographer, however.

petiepooo 13y ago

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

drivebyacct2 13y ago

Or just use a proper OpenPGP card.

edwintorok 13y ago

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/keyformat.txt https://gitorious.org/gnupg-org/gnupg/blobs/master/agent/key... 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-pgp-key http://budts.be/weblog/2012/08/ssh-authentication-with-your-...

oneofthose 13y ago

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/ https://www.crypto-stick.com/

rdl 13y ago

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.

atoponce 13y ago

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

atoponce 13y ago
Ah. I am an id10t. Helps if I type the command correctly. Carry on.

marshallford 13y ago

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