970

I want to use multiple private keys to connect to different servers or different portions of the same server (my uses are system administration of server, administration of Git, and normal Git usage within the same server). I tried simply stacking the keys in the id_rsa files to no avail.

Apparently a straightforward way to do this is to use the command

ssh -i <key location> login@server.example.com 

That is quite cumbersome.

Any suggestions as to how to go about doing this a bit easier?

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Justin
  • 9,773
  • 3
  • 14
  • 7
  • 3
    I wrote [this article](https://yayimorphology.org/ssh-identities-made-easy.html) that goes in depth on various configurations and their strength/shortcomings. – Raffi May 02 '20 at 10:46

21 Answers21

1368

From my .ssh/config:

Host myshortname realname.example.com
    HostName realname.example.com
    IdentityFile ~/.ssh/realname_rsa # private key for realname
    User remoteusername

Host myother realname2.example.org
    HostName realname2.example.org
    IdentityFile ~/.ssh/realname2_rsa  # different private key for realname2
    User remoteusername

Then you can use the following to connect:

ssh myshortname

ssh myother

And so on.

Stephen Sabatini
  • 313
  • 2
  • 12
Randal Schwartz
  • 30,888
  • 4
  • 35
  • 57
  • 27
    Thanks Randal! I did some digging into the .ssh/config and found this: http://github.com/guides/multiple-github-accounts Pointed me in the right direction. – Justin Mar 10 '10 at 19:30
  • 6
    This was a great help (in addition to http://stackoverflow.com/a/3828682/169153). If you want to use putty keys follow this document here: http://blog.padraigkitterick.com/2007/09/16/using-putty-ssh-keys-with-openssh-on-ubuntu – Urda Mar 14 '12 at 23:14
  • 2
    I found this post very helpful. One error I made when creating the config file was I put a .txt file in the .ssh folder instead of running the "touch" command to create a config file. – M_x_r Dec 22 '12 at 18:17
  • are there any other ways? Like an environment variable? – Jürgen Paul Jul 23 '13 at 09:29
  • great answer.. one comment, in my case at least --- the private keys need to be in different folders. Don't exactly know why, but is the only way it works – user1236048 Sep 04 '13 at 12:33
  • 66
    Note that you can also specify multiple `IdentityFile` entries for the same `Host`, which are then tried in order when connecting. – sschuberth Oct 02 '13 at 09:28
  • 1
    Adding the comment `# private key for realname` can cause error `garbage at end of line; "#"`. – Karl Richter May 18 '15 at 09:17
  • This howto youtube video nicely echoes @RandalSchwartz's answer and gives a more complete WSGWYG feel to his answer : https://www.youtube.com/watch?v=9u4QPEMFK4A – Vietnhi Phuvan Aug 03 '15 at 15:15
  • 1
    This saved me a ton of hassle on my Windows box. Thanks! ssh-agent can suck it – Derek Aug 23 '15 at 01:59
  • 2
    If you are on windows, and your ssh client seems to be ignoring your .ssh/config file, see this answer: http://stackoverflow.com/questions/9513712/git-ssh-client-for-windows-and-wrong-path-for-ssh-config-file – Zachary Yates Aug 27 '15 at 21:14
  • 16
    Use `IdentitiesOnly yes` to prevent ~/.ssh/id_rsa or any other identities. (This was originally an edit) – user3338098 Nov 02 '15 at 17:30
  • And (just for comparision, like for/from github above) [here it is also confirmed, according to Bitbucket](https://developer.atlassian.com/blog/2016/04/different-ssh-keys-multiple-bitbucket-accounts/) – Frank Nocke Apr 11 '18 at 10:48
  • 1
    It is worth understanding, where this `~/ssh/config` [stuff is coming from](https://www.ssh.com/ssh/config/) – Frank Nocke Apr 11 '18 at 10:50
  • 1
    Note that if you are using an ssh-agent to hold your keys, IdentityFile in your config can point to the *public* key file. That way, ssh can see that the file mentioned in the config is already present in the agent, which it wouldn't be able to do if the key was private (assuming you have a pass phrase on your private key). – Brian Minton Aug 20 '18 at 17:58
  • Does this config file somehow get picked up by the `ssh` utility? Is that the default for which it looks? – MadPhysicist Feb 21 '19 at 04:46
  • Awesome ,thanks! Note that you can also use this if you only ever use the same connection... It saves you having to type the user every time – Tobias Feil Feb 04 '20 at 11:35
  • As per the [serverfault question](https://serverfault.com/questions/139870/stop-ssh-client-from-offering-all-the-public-keys-it-can-find/421815) and the [comment here](https://stackoverflow.com/questions/2419566/best-way-to-use-multiple-ssh-private-keys-on-one-client#comment54751766_2419609) this will not actually stop you from offering the _wrong_ identity to github, and you need `IdentitiesOnly yes` also, in principle. (In fact the latter also does not work for me) – dan mackinlay May 11 '20 at 07:48
442

You can instruct ssh to try multiple keys in succession when connecting. Here's how:

$ cat ~/.ssh/config
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_rsa_old
IdentityFile ~/.ssh/id_ed25519
# ... and so on

$ ssh server.example.com -v
....
debug1: Next authentication method: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa_old
debug1: read PEM private key done: type RSA
....
[server ~]$

This way you don't have to specify what key works with which server. It'll just use the first working key.

Also you would only enter a passphrase if a given server is willing to accept the key. As seen above ssh didn't try to ask for a password for .ssh/id_rsa even if it had one.

Surely it doesn't outbeat a per-server configuration as in other answers, but at least you won't have to add a configuration for all and every server you connect to!

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
spacesix
  • 4,763
  • 1
  • 8
  • 4
  • 13
    This is a fantastic solution for the question asked, but didn't quite meet the needs that the asker intended. For me, it was exactly the right solution and it perfectly meets the need for the "Best way to use multiple SSH private keys on one client". – Wade Aug 08 '16 at 17:28
  • 3
    This does not seem to work under the Host declaration in config file – Maksim Luzik Apr 12 '17 at 13:17
  • 41
    This doesn't work well with git, as if you have two github deploy keys, the first one in the list is valid and will work, but then github will complain that the repository doesn't match. – Adam Reis Sep 12 '17 at 04:38
  • This is a more dynamic approach, works great in certain situations. Thanks for this – gbolo Oct 25 '18 at 14:28
  • 1
    If the SFTP/target server has security policies that lock the account (say after 3 multiple failed connection attempts), would this not end up locking the account. A connection is attempted, but with a 'wrong key' file – alchemist.gamma Nov 02 '18 at 18:07
  • 9
    Be aware if you have something like fail2ban on those servers. You might end up in one of those jails... because of the failed attempts generated by the other keys... – Piccolo Apr 18 '19 at 09:21
  • Perfect, this was exactly what I was looking for. From now on my workstations will look like this. IdentityFile ~/.ssh/id_rsa_shared_nopass , IdentityFile ~/.ssh/id_rsa_shared , IdentityFile ~/.ssh/id_rsa_local_nopass , IdentityFile ~/.ssh/id_rsa_local Where the local shared are shared between different workstations I use to get access to for instance wallboards etc. while local i bound to a specific workstation. The _nopass will be if it require password or not. Just to have a security ladder. – Griffin Sep 27 '19 at 07:49
  • @AdamReis For git one can use the `core.sshCommand` option instead (`ssh -i ~/.ssh/key1`) – olejorgenb Oct 01 '19 at 20:51
  • if you have two github accounts, you will need different ssh keys for that and you can use the approach suggested here in your ssh config: https://stackoverflow.com/a/23751734/1764764 – Simon Ndunda Jan 08 '20 at 20:18
267

The answer from Randal Schwartz almost helped me all the way. I have a different username on the server, so I had to add the User keyword to my file:

Host           friendly-name
HostName       long.and.cumbersome.server.name
IdentityFile   ~/.ssh/private_ssh_file
User           username-on-remote-machine

Now you can connect using the friendly-name:

ssh friendly-name

More keywords can be found on the OpenSSH man page. NOTE: Some of the keywords listed might already be present in your /etc/ssh/ssh_config file.

Community
  • 1
  • 1
peron
  • 2,839
  • 1
  • 13
  • 6
  • If I am not mistaken the user you usually specify directly in the url when connecting with user@host – a1an Jun 18 '13 at 11:07
  • 4
    I prefer to use the 'Port' keyword also. Another interesting keyword is 'StrictHostKeyChecking'. – Ethan Sep 24 '13 at 23:00
181

The previous answers have properly explained the way to create a configuration file to manage multiple ssh keys. I think, the important thing that also needs to be explained is the replacement of a host name with an alias name while cloning the repository.

Suppose, your company's GitHub account's username is abc1234. And suppose your personal GitHub account's username is jack1234

And, suppose you have created two RSA keys, namely id_rsa_company and id_rsa_personal. So, your configuration file will look like below:

# Company account
Host company
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_company

# Personal account
Host personal
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_personal

Now, when you are cloning the repository (named demo) from the company's GitHub account, the repository URL will be something like:

Repo URL: git@github.com:abc1234/demo.git

Now, while doing git clone, you should modify the above repository URL as:

git@company:abc1234/demo.git

Notice how github.com is now replaced with the alias "company" as we have defined in the configuration file.

Similary, you have to modify the clone URL of the repository in the personal account depending upon the alias provided in the configuration file.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
oblivion
  • 4,595
  • 1
  • 27
  • 50
  • 16
    I wish I could upvote this answer more than once... this is the correct way to approach the issue, and it's safer and faster than other options. More scalable too (allows for defining different keys for the *same* hostname) – Guy Mar 28 '18 at 08:03
  • 5
    Waste no more time, this is THE answer. Many thanks. – Luis Milanese Apr 24 '18 at 14:04
  • 2
    I really wish I'd found this answer earlier...but better late than never, Thanks much! – Hildy Jan 22 '19 at 03:27
  • 2
    Great explanation! Works perfect for me. And if you forgot to clone the repo with the alias you can often edit the remote url of origin afterwards. – tkahn Jan 22 '19 at 14:10
  • 2
    only pay attencion because config file must be (chmod 600) – Christiano Matos Sep 05 '19 at 15:00
  • 1
    I was recently setting up two different dev.azure.com repos when I needed separate keys for those and this answer is so much simpler and cleaner than others, awesome - much appreciated! – Damian Borowski Dec 04 '19 at 14:44
  • 2
    It's not stated explicitly, but this works around a major gotcha when trying to use multiple keys with GitHub: since you always log into GitHub as the same user `git`, any key that's saved on any GitHub account will allow for SSH login. But after the SSH login GitHub will then check if the key used is authorized for the specific action you're trying (e.g. checking out a repo), and that will fail if you have the wrong key. But the SSH part succeeded, so SSH will not try another key. This solution works around that by introducing host name aliases. Brilliant! – ntc2 Jan 26 '20 at 01:55
  • 3
    It's also worth mentioning that if you use `ssh-agent`, then you should also add the `IdentitiesOnly yes` option to you config, otherwise `ssh-agent` will attempt connecting to a given alias with a key for a different alias if their hostnames match. – William Stanley Mar 02 '20 at 08:13
  • If you don't want to modify the repository url every time you clone a repo, you can have `Host company github.com` for one of the entries in the config file, which will behave as the 'default'. – handris May 27 '21 at 10:25
113
ssh-add ~/.ssh/xxx_id_rsa

Make sure you test it before adding with:

ssh -i ~/.ssh/xxx_id_rsa username@example.com

If you have any problems with errors sometimes changing the security of the file helps:

chmod 0600 ~/.ssh/xxx_id_rsa
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
user420807
  • 1,147
  • 1
  • 7
  • 2
49
  1. Generate an SSH key:

    $ ssh-keygen -t rsa -C <email1@example.com>
    
  2. Generate another SSH key:

    $ ssh-keygen -t rsa -f ~/.ssh/accountB -C <email2@example.com>
    

    Now, two public keys (id_rsa.pub, accountB.pub) should be exists in the ~/.ssh/ directory.

    $ ls -l ~/.ssh     # see the files of '~/.ssh/' directory
    
  3. Create configuration file ~/.ssh/config with the following contents:

    $ nano ~/.ssh/config
    
    Host bitbucket.org
        User git
        Hostname bitbucket.org
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa
    
    Host bitbucket-accountB
        User git
        Hostname bitbucket.org
        PreferredAuthentications publickey
        IdentitiesOnly yes
        IdentityFile ~/.ssh/accountB
    
  4. Clone from default account.

    $ git clone git@bitbucket.org:username/project.git
    
  5. Clone from the accountB account.

    $ git clone git@bitbucket-accountB:username/project.git
    

See More Here

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Sajib Khan
  • 18,145
  • 4
  • 50
  • 65
26

I would agree with Tuomas about using ssh-agent. I also wanted to add a second private key for work and this tutorial worked like a charm for me.

Steps are as below:

  1. $ ssh-agent bash
  2. $ ssh-add /path.to/private/key e.g ssh-add ~/.ssh/id_rsa
  3. Verify by $ ssh-add -l
  4. Test it with $ssh -v <host url> e.g ssh -v git@assembla.com
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Wahib Ul Haq
  • 3,742
  • 3
  • 39
  • 38
  • 4
    Having used `ssh-agent` for years, I've recently switched to using Gnome's `gnome-keyring` within my `i3` wm. The reason is simple: Gnome's Keyring manager automagically handles adding and removing ssh keys without me having to remember to `ssh-add`. In addition providing me with a single password to unlock them (and timeout on a specified time, for security). To each his own. Since I use gnome settings on Arch, it was plug n play with my setup. If you are anti-gnome, ignore this comment. – eduncan911 May 26 '15 at 17:01
  • @eduncan911, I agree that gnome-keyring can be helpful, but it doesn't really handle ed25519 keys, so that for me is a non-starter. Update: I see from https://wiki.archlinux.org/index.php/GNOME/Keyring#Cannot_handle_ECDSA_and_Ed25519_keys that it now uses the system's ssh-agent so that's no longer a problem. – Brian Minton Aug 20 '18 at 18:03
15

I had run into this issue a while back, when I had two Bitbucket accounts and wanted to had to store separate SSH keys for both. This is what worked for me.

I created two separate ssh configurations as follows.

Host personal.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /Users/username/.ssh/personal
Host work.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /Users/username/.ssh/work

Now when I had to clone a repository from my work account - the command was as follows.

git clone git@bitbucket.org:teamname/project.git

I had to modify this command to:

git clone git@**work**.bitbucket.org:teamname/project.git

Similarly the clone command from my personal account had to be modified to

git clone git@personal.bitbucket.org:name/personalproject.git

Refer this link for more information.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Ananth Pai
  • 1,629
  • 12
  • 14
14

Now, with the recent version of Git, we can specify sshCommand in the repository-specific Git configuration file:

  [core]
      repositoryformatversion = 0
      filemode = true
      bare = false
      logallrefupdates = true
      sshCommand = ssh -i ~/.ssh/id_rsa_user
   [remote "origin"]
      url = git@bitbucket.org:user/repo.git
      fetch = +refs/heads/*:refs/remotes/origin/*
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Naga Kiran
  • 8,006
  • 5
  • 39
  • 49
9

Use ssh-agent for your keys.

Tuomas Pelkonen
  • 7,559
  • 2
  • 28
  • 31
6

Here is the solution that I used inspired from the answer of sajib-khan. The default configuration is not set; it's my personal account on GitLab and the other specified is my company account. Here is what I did:

Generate the SSH key

ssh-keygen -t rsa -f ~/.ssh/company -C "name.surname@company.com"

Edit the SSH configuration

nano ~/.ssh/config
    Host company.gitlab.com
    HostName gitlab.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/company

Delete the cached SSH key(s)

ssh-add -D

Test it!

ssh -T git@company.gitlab.com

Welcome to GitLab, @hugo.sohm!

ssh -T git@gitlab.com

Welcome to GitLab, @HugoSohm!

Use it!

Company account

git clone git@company.gitlab.com:group/project.git

Personal/default account

git clone git@gitlab.com:username/project.git

Here is the source that I used.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Hugo Sohm
  • 1,451
  • 2
  • 9
  • 29
3

For me, the only working solution was to simply add this in file ~/.ssh/config:

Host *
  IdentityFile ~/.ssh/your_ssh_key
  IdentityFile ~/.ssh/your_ssh_key2
  IdentityFile ~/.ssh/your_ssh_key3
  AddKeysToAgent yes

your_ssh_key is without any extension. Don't use .pub.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
amdev
  • 2,264
  • 3
  • 23
  • 40
  • Works but loads says "load pubkey "path/.ssh/key": invalid format" – Norman Potts Jul 20 '20 at 16:16
  • This is something that has working for me and it's –a little bit– similar to yours: `$ eval "$(ssh-agent -s)"` `$ ssh-add ~/.ssh/{private_key}` `$ git clone git@{alias}:{github_user}/{repo}.git` then on `~/.ssh/config` `Host github.com-{alias}` `HostName github.com` `PreferredAuthentications publickey` `IdentityFile ~/.ssh/{private_key}` and on `{repo}/.git/config` `[remote "origin"]` `url = git@github.com-{alias}:{github_user}/{repo}.git` `fetch = +refs/heads/*:refs/remotes/origin/*`. [gist](https://gist.github.com/viniciusCamargo/b60677babe91ca65f7580a6c233334c9) – vcamargo Jan 13 '21 at 19:33
2

Multiple key pairs on GitHub

1.0 SSH configuration file

1.1 Create ~/.ssh/config

1.2 chmod 600 ~/.ssh/config (must)

1.3 Input the following into the file:

Host pizza

HostName github.com

PreferredAuthentications publickey # optional

IdentityFile ~/.ssh/privatekey1

Case A: Fresh new Git clone

Use this command to Git clone:

$ git clone git@pizza:yourgitusername/pizzahut_repo.git

Note: If you want to change the host name “pizza” of .ssh/config in the future, go into the Git cloned folder, edit .git/config file URL line (see case B)

Case B: Already have Git clone folder

2.1 Go to the cloned folder, and then go into the .git folder

2.2 Edit configuration file

2.3 Update the URL from *old to new:

(Old) URL = git@github.com:yourgitusername/pizzahut_repo.git

(New) URL = git@pizza:yourgitusername/pizzahut_repo.git

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Chris
  • 46
  • 3
2

For those who are working with I would highly recommend working with EC2 Instance Connect.

Amazon EC2 Instance Connect provides a simple and secure way to connect to your instances using Secure Shell (SSH).

With EC2 Instance Connect, you use AWS Identity and Access Management (IAM) policies and principles to control SSH access to your instances, removing the need to share and manage SSH keys.

After installing the relevant packages (pip install ec2instanceconnectcli or cloning the repo directly) you can connect very easy to multiple EC2 instances by just changing the instance id:

enter image description here


What is happening behind the scenes?

When you connect to an instance using EC2 Instance Connect, the Instance Connect API pushes a one-time-use SSH public key to the instance metadata where it remains for 60 seconds. An IAM policy attached to your IAM user authorizes your IAM user to push the public key to the instance metadata.

The SSH daemon uses AuthorizedKeysCommand and AuthorizedKeysCommandUser, which are configured when Instance Connect is installed, to look up the public key from the instance metadata for authentication, and connects you to the instance.

(*) Amazon Linux 2 2.0.20190618 or later and Ubuntu 20.04 or later comes preconfigured with EC2 Instance Connect. For other supported Linux distributions, you must set up Instance Connect for every instance that will support using Instance Connect. This is a one-time requirement for each instance.


Links:

Set up EC2 Instance Connect
Connect using EC2 Instance Connect
Securing your bastion hosts with Amazon EC2 Instance Connect


RtmY
  • 7,115
  • 6
  • 51
  • 64
1

You can create a configuration file named config in your ~/.ssh folder. It can contain:

Host aws
    HostName *yourip*
    User *youruser*
    IdentityFile *idFile*

This will allow you to connect to machines like this

 ssh aws
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
1

IMPORTANT: You must start ssh-agent

You must start ssh-agent (if it is not running already) before using ssh-add as follows:

eval `ssh-agent -s` # start the agent

ssh-add id_rsa_2 # Where id_rsa_2 is your new private key file

Note that the eval command starts the agent on Git Bash on Windows. Other environments may use a variant to start the SSH agent.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
danday74
  • 38,089
  • 29
  • 169
  • 214
1

As mentioned on a Atlassian blog page, generate a config file within the .ssh folder, including the following text:

#user1 account
 Host bitbucket.org-user1
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user1
     IdentitiesOnly yes

 #user2 account
 Host bitbucket.org-user2
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user2
     IdentitiesOnly yes

Then you can simply checkout with the suffix domain and within the projects you can configure the author names, etc. locally.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
dgbt
  • 241
  • 1
  • 6
1

On Ubuntu 18.04 (Bionic Beaver) there is nothing to do.

After having created an second SSH key successfully the system will try to find a matching SSH key for each connection.

Just to be clear you can create a new key with these commands:

# Generate key make sure you give it a new name (id_rsa_server2)
ssh-keygen

# Make sure ssh agent is running
eval `ssh-agent`

# Add the new key
ssh-add ~/.ssh/id_rsa_server2

# Get the public key to add it to a remote system for authentication
cat ~/.ssh/id_rsa_server2.pub
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
GiorgosK
  • 4,369
  • 2
  • 25
  • 21
1

I love the approach to set the following in file ~/.ssh/config:

# Configuration for GitHub to support multiple GitHub  keys
Host  github.com
  HostName github.com
  User git

# UseKeychain adds each keys passphrase to the keychain so you
# don't have to enter the passphrase each time.
  UseKeychain yes

# AddKeysToAgent would add the key to the agent whenever it is
# used, which might lead to debugging confusion since then
# sometimes the one repository works and sometimes the
# other depending on which key is used first.
#  AddKeysToAgent yes

# I only use my private id file so all private
# repositories don't need the environment variable
# `GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa"` to be set.
  IdentityFile ~/.ssh/id_rsa

Then in your repository you can create a .env file which contains the ssh command to be used:

GIT_SSH_COMMAND="ssh -i ~/.ssh/your_ssh_key"

If you then use e.g. dotenv the environment environment variable is exported automatically and whoop whoop, you can specify the key you want per project/directory. The passphrase is asked for only once since it is added to the keychain.

This solution works perfectly with Git and is designed to work on a Mac (due to UseKeychain).

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
blackjacx
  • 5,912
  • 5
  • 34
  • 44
0

On CentOS 6.5 running OpenSSH_5.3p1 and OpenSSL 1.0.1e-fips, I solved the problem by renaming my key files so that none of them had the default name.

My .ssh directory contains id_rsa_foo and id_rsa_bar, but no id_rsa, etc.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Chris Owens
  • 927
  • 1
  • 8
  • 15
  • And how does the keys get used? Is there any auto-detection? – robsch May 22 '17 at 06:44
  • See Randal Schwartz's answer for a way to select the correct key for a given host https://stackoverflow.com/questions/2419566/best-way-to-use-multiple-ssh-private-keys-on-one-client/2419609#2419609 – Chris Owens May 23 '17 at 16:35
  • Yes, that makes it more explicit. Even using the `-i` option might result in something like `no such identity: /home/embo/.ssh/id_rsa: No such file or directory`. – Peter Mortensen Jun 05 '20 at 20:41
-1

You can try this sshmulti npm package for maintaining multiple SSH keys.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Anto Khan
  • 43
  • 1
  • 4
  • 1
    I'd strongly recommend _not_ using npm for anything like this. It had a cascade of dependencies, which, on brief inspection, include a range of lone-wolf developers, several year old packages. The sshmulti npm page itself declares that it is untested. – Jack Wasey May 02 '20 at 10:25