2

Given that any application running as the logged in user will have read access to that user's ~/.ssh folder, it seems trivial for the application to copy that user's private key and send it over the network.

Is maintaining SSH keys under ~/.ssh considered unsafe for this reason? If so, what is the recommended way to manage SSH keys?

Amol D
  • 23
  • 3
  • If I remember correctly, a OpenSSH server will refuse to start (as signal that something is very wrong) if the private keys are accessible by more than root. (Can´t try it right now) – deviantfan Aug 26 '15 at 01:55

5 Answers5

5

As Naftuli Tzvi Kay stated a well worn solution is using a hardware device to manage your keys. Some alternatives for a software solution include:

  • Making your private keys only readable by root / sudo
  • Encrypting your private key with a password, so at least it will be non trivial for the attacker to crack it if they do steal
  • Storing them in an encrypted directory somewhere on your local machine
Nic Barker
  • 1,170
  • 7
  • 11
  • @nic-barter Thanks for the link to Martin Klepmann's blog post, that was very informative and relevant. I have now converted my private keys to PKCS#8 with a strong password (also tested that my ssh access works fine after converting the private keys to PKCS#8). – Amol D Aug 26 '15 at 04:26
  • Great to hear, we would have far fewer problems with compromised keys if standard practise was to encrypt with a strong passphrase. – Nic Barker Aug 26 '15 at 04:27
0

Just don't keep your private keys world readable. Not everything in ~/.ssh is private keys. authorized_keys and stuff is fine to read.

Also, you may benefit from doing some sort of network monitoring (maybe even deep packet inspection, though that's probably not that efficient) and/or auditing regarding user sessions so at least you can detect if they send keys back to the mothership you can generate new ones.

Alternatively as stated previously you could store it on a hardware device, but my issue with that is you could lose the device.

Michael Bailey
  • 109
  • 5
  • In terms of network monitoring, I would assume any keys that got stolen and sent somewhere would be transferred over an encrypted connection, and it would be basically impossible to check that this was being done. – Nic Barker Aug 26 '15 at 02:45
  • 1
    That's one hell of an assumption... – Michael Bailey Aug 26 '15 at 02:49
  • A lot of people use tools like ncat and curl since they know it'll be installed in the victim, which both (usually) mean unencrypted. I've even seen wput. Additionally, seeing an encrypted session to another host you've never heard of is probably enough of an alarm to further investigate. Log files and history keeping help in this regard. – Michael Bailey Aug 26 '15 at 02:51
  • 1
    Good point on the tools. I guess it depends pretty heavily on the environment - on consumer Mac OS X with a whole bunch of sass products installed (dropbox, evernote etc) there are thousands of encrypted calls being made to random endpoints... it's hard to keep track with all the noise these days. – Nic Barker Aug 26 '15 at 03:04
  • You can usually sort by hostname or process making that call. They have a lot of endpoints but not a lot of processes. – Michael Bailey Aug 26 '15 at 03:35
0

Store your private keys on a hardware security device.

Naftuli Kay
  • 6,715
  • 9
  • 47
  • 75
0

Given that any application running as the logged in user will have read access to that user's ~/.ssh folder, it seems trivial for the application to copy that user's private key and send it over the network.

Yes, that is correct. A few safeguards to prevent ex-filtration of your private key are:

  • Role accounts: Run any untrusted program using a role account of its own. This way an application will not have read permissions on your private key. This is the reason why most standard server applications run under their own restricted role accounts. Eg. nginx, mysql, apache, PassengerAgent run as nginx, mysql, www-data, nobody respectively

  • Guard your private key with a strong passphrase. This way, even if its compromised, it'll make it difficult to decrypt it using brute force. You can use ssh-agent to avoid entering the password each time.

  • Make sure the permissions on your private key are set to 400 -r--------.

There are applications that need to run as you (user), eg. desktop applications like google chrome and media player. Make sure you download these applications from a trusted source. Do not install programs from untrusted sources or blindly add PPAs to your software catalog without verifying the authenticity.

Community
  • 1
CodeExpress
  • 2,422
  • 13
  • 10
0

In addition to permissions on the files within ~/.ssh, depending on the platform, you could monitor any access of the files within the directory using auditd. This would allow you to see who/what is accessing those files at any time and alert you to any unknown/unsavory activity.

A. Smith
  • 1
  • 1