I've been creating multiple SSH keys in Debian for different accounts (namely Digital Ocean, GitHub, and Bitbucket), but it's getting messy very quickly.

Listing the contents in my .ssh folder, I get:

digOcn digOcn.pub github github.pub id_rsa id_rsa.pub

(I use the id_rsa key for Bitbucket.)

I do the eval 'ssh-agent -s' thing, and then "add" the keys like so:

  • ssh-add ~/.ssh/github (and then entering passphrase)

  • ssh-add ~/.ssh/id_rsa (and then entering passphrase)

  • ssh-add ~/.ssh/digOcn (When I try to add digOcn, it says "Permission denied". I don't try sudo to avoid messing something up and also because the other keys didn't require sudo.)

Here's the confusing part: performing ssh-add -l gives me this:

2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 /home/USER/.ssh/id_rsa (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 /home/USER/.ssh/github (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 github (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 USER@COMPUTER_NAME (RSA)

Yes, I have added SSH keys in the past, but I can't retrace what I've done. That's probably why there is both /home/USER/.ssh/github and github.

What have I done wrong? How should I be organising my SSH keys?

  • 1
    Why do you want multiple SSH keys? SSH keys identify the user using them, not the destination they are accepted on.
    – phemmer
    May 28 '17 at 2:17
  • @Patrick I cannot use the same SSH key for multiple accounts, as far as I understand. May 28 '17 at 2:18
  • Wherever you got that information from is incorrect. Using multiple SSH keys to identify the same user introduces numerous difficulties, as you are experiencing.
    – phemmer
    May 28 '17 at 2:23
  • @Patrick Thanks, I will try to do that, but I'll leave that issue separate from this thread in case anyone genuinely needs multiple SSH keys. May 28 '17 at 2:34
  • 1
    @bitofagoob one key per user per machine is a good practice. The challenges discussed here are when the ssh client has multiple different keys it could use.
    – phemmer
    May 30 '17 at 21:34

First, there is nothing wrong with using different keys for different accounts. This is pretty much overkill for interactive shells, but there are legitimate reasons for doing it when you're dealing with other, non-interactive services. For example a few years ago GitHub started allowing stronger SSH keys, while Bitbucket insisted on using weaker ones for a while longer. The right action at the time was to use different keys for accessing GitHub and Bitbucket.

Another example is rsync. If you're using rsync for, say, deploying files to a web server then you probably want dedicated SSH keys for it. These allow you to set different permissions than you'd normally use with your interactive account.

Back to your question about managing multiple keys: SSH lets you set different options for different destinations. In order to do that you need to edit a file ~/.ssh/config like this:

Host  bitbucket.org
    User                    hg
    IdentitiesOnly          yes
    IdentityFile            /home/user/.ssh/bitbucket

Host  github.com  gist.github.com
    User                    git
    IdentitiesOnly          yes
    IdentityFile            /home/user/.ssh/github

The file ~/.ssh/config should have permissions 0600 (I don't remember right now if that's enforced by SSH or not, but it certainly doesn't hurt).

You can, of course, also use the same mechanism for interactive shells, so set things like remote username (if different from the local one), remote port, shorten the hostname, etc. E.g.:

Host  sm
    Hostname                sphygmomanometer.example.com
    User                    human
    Port                    2222

Then you can just run

ssh sm

instead of

ssh -p 2222 human@sphygmomanometer.example.com

Wildcards are also allowed:

Host *
    ControlPath             ~/.ssh/ctl-%u-%r-%h-%p
    ControlMaster           auto
    ControlPersist          5m

Read the manual for more details.

Last but not least: don't "do the eval 'ssh-agent -s' thing". Contrary to the popular belief, there are severe security implications to that. The right way to do it is like this:

ssh-agent /bin/bash

(then enter your key passwords when you're prompted). That's all, don't do it key by key, or any other way.

This runs a new shell in which your keys are loaded, and when you want to revoke access you just exit this shell. If you "do the eval 'ssh-agent -s' thing" then authentication agents are left running long after you log off, and they can (and eventually will) be used for unauthorized access.

Edit: Try this little experiment:

  1. eval $(ssh-agent -s)
  2. log off, or kill the terminal
  3. log in again, or open a new terminal
  4. pgrep ssh-agent

Nobody's killing these ssh-agents, they hang around until the next reboot, ready to be used by the latest malware.

  • What do you have against eval $(ssh-agent -s)? Is this only about forgetting to kill the agent when you log out? That doesn't warrant the generic scaremongering description you give it. May 28 '17 at 21:59
  • @Gilles Added a proof of concept. It's a well-known problem, just not by people that should, actually, know it. May 29 '17 at 4:07
  • @Gilles Here's a more detailed explanation. See here for many more of the same. May 29 '17 at 4:14
  • Describing that as “severe security implications” is overrated. On a personal computer, it's common for people to basically never log out except to reboot. For a computer in a physically secure location, it isn't an issue since accessing the agent would require authenticating as the user. So this only matters on a computer where the user has logged out and then an attacker gains physical access. It's a security concern, but not a particularly severe one, and one that is fixed by ensuring that you kill the agent when logging out. May 29 '17 at 10:42
  • @Gilles That is, until a local execution exploit is found. Then a popup ad gets to use your SSH credentials. All exploits are hypothetical until they actually happen, you know. May 29 '17 at 10:56

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.