I have come across this problem a couple of times when creating build servers with keyed authentication.

I was wondering if anyone else has experience this. I have a couple of keys for my current user that may connect to different machines. Let say machine1 and machine2. I have pasted my public key into their respective authorized_keys file. The first one I have named the first key id_rsa and the second key bender.

When I try to connect to bender I get the following output with my verbose ssh connection

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bozo/.ssh/.ssh/identity
debug1: Trying private key: /home/bozo/.ssh/.ssh/id_rsa
debug1: Trying private key: /home/bozo/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

It only offers the id_rsa key, as you can see above. Is this correct? If so why? How do I get it to offer more keys? I know it is a problem I see intermittently, because I at home I have multiple keys without much trouble.

I would also appreciate a overview on how the pub and private keys interact with the client and server. I thought I had a pretty decent idea, but apparently I am missing something.

Please and thank you.

3 Answers 3


By default, ssh searches for id_dsa and id_rsa files. The keys do not have to be named like this, you can name it mykey just as well, or even place it in a different directory. However, if you do either of those, then you need to explicitly reference the key in the ssh command like so:

ssh user@server -i /path/to/mykey

If a command does not accept -i, e.g. sshfs, use the IdentityFile option:

sshfs -o IdentityFile=/path/to/mykey user@host:/path/on/remote /mountpoint

How It Works

When generating a key, you'll get two files: id_rsa (private key) and id_rsa.pub (public key). As their names suggest, the private key should be kept secret and the public key can be published to the public.

Public-key authentication works with a public and a private key. Both the client and the server have their own keys. When installing openssh-server the server public and private keys are generated automatically. For the client, you'll have to do that on your own.

When you (client) connect with a server, public keys are exchanged. You'll receive the servers one, and the server yours. The first time you receive the server public key, you'll be asked to accept it. If this public key changes over a time, you'll be warned because a possible MITM (Man in the middle) attack is going on, intercepting the traffic between the client and the server.

The server checks whether you are allowed to connect (defined in /etc/ssh/sshd_config) and if your public key is listed in the ~/.ssh/authorized_keys file. Possible reasons why the public key is denied:

  • /etc/ssh/sshd_config:
    • AllowUsers or AllowGroups is specified, but your server user is not listed in the groups or users list (default not defined, placing no restriction on the users or groups from logging in).
    • DenyUsers or DenyGroups is specified and you're in the users or groups list.
    • You're trying to login as root, but PermitRootLogin is set to No (default yes).
    • PubkeyAuthentication is set to No (default yes).
    • AuthorizedKeysFile is set to a different location, and the public keys are not added to that file (default .ssh/authorized_keys, relative to home dir)
  • ~/.ssh/authorized_keys: your public key is not added in this file (note that this file is read as root user)

Using multiple keys

It's not uncommon to use multiple keys. Instead of running ssh user@host -i /path/to/identity_file, you can use a configuration file, ~/.ssh/config.

Common settings are the IdentityFile (the keys) and port. The next configuration will check "id_dsa" and "bender" only when connecting with ssh youruser@yourhost:

Host yourhost
   IdentityFile ~/.ssh/id_dsa
   IdentityFile ~/.ssh/bender

If you omit Host yourhost, the settings will apply to all SSH connections. Other options can also be specified for this host match, like User youruser, Port 2222, etc. This would allow you to connect with the shorthand ssh yourhost instead of ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender.

  • 1
    why do I need to specify the key? the whole point is so I can ssh to the machine easier.
    – myusuf3
    Mar 17, 2011 at 18:28
  • 2
    @StevenRoose from ssh_config(5): The file name may use the tilde syntax to refer to a user's home directory or one of the following escape characters: '%d' (local user's home directory), '%u' (local user name), '%l' (local host name), '%h' (remote host name) or '%r' (remote user name). It is not possible to specify wild cards, but this should be convenient enough I guess. Be aware that a server has to probe each key you sent, so specifying less keys is better. Wildcards on Host work, see again the manual page of ssh_config(5).
    – Lekensteyn
    Apr 29, 2013 at 14:43
  • 2
    @therobyouknow You do not have to create a unique key pair for every machine. Usually you have few keys, and append the public key of one of the keys to the .ssh/authorized_keys file on the remote machines. If you use the standard .ssh/id_rsa file name (or id_dsa, id_ecdsa or the recent id_ed25519), then ssh will try this automatically and you do not need to specify IdentityFile in your config (or the -i path/to/id_file parameter for ssh).
    – Lekensteyn
    Feb 27, 2014 at 16:04
  • 4
    I love answers that go beyond the required detail and take the time to explain the concept. Wonderful job! +1 May 28, 2016 at 21:43
  • 1
    @landed It is the host of the SSH server (it could be an IP address or DNS name). I have tried to clarify that section, hopefully it helps.
    – Lekensteyn
    Jun 14, 2017 at 13:34

My favourite method allows the private key to be selected automatically

IdentityFile ~/.ssh/%l_%r@%h_id_rsa

SSH will replace %l with the local machine name, %r with the remote username, and %h with the remote host, thus if I wanted to connect from my machine called foo to bar as user, I run:

ssh bar

And ssh would automatically use:


As the local host is also stored, this allows for home directories shared over NFS (different key per machine!) or even identifying which machine the key was meant to be on...


In consideration of StevenRoose's comment that it takes longer to specify many keys, and I happen to be playing around with a lot of keys, I would like to suggest my personal solution.

I create a symlink to the key that I want to use at the time, and since that only changes infrequently depending on which project I'm working on, I am happy with it.

Here I have linked to my keys for machines running under virtualbox:

$ cd .ssh/
$ ln -s adam_vbox-id_rsa.pub id_rsa.pub
$ ln -s adam_vbox-id_rsa id_rsa

$ ls -l
total 12
-rw------- 1 adam adam 1675 2013-10-04 02:04 adam_vbox-id_rsa
-rw-r--r-- 1 adam adam  396 2013-10-04 02:04 adam_vbox-id_rsa.pub
lrwxrwxrwx 1 adam adam   16 2013-10-04 02:17 id_rsa -> adam_vbox-id_rsa
lrwxrwxrwx 1 adam adam   20 2013-10-04 02:17 id_rsa.pub -> adam_vbox-id_rsa.pub
-rw-r--r-- 1 adam adam 3094 2013-10-04 02:09 known_hosts

One could also add a really quick script to change over to another set without having to manually type the ln command again.

Again, this isn't a solution for two keys only, but for a greater number, it might be workable.

  • 1
    I just add an alias in by bash_profile for each server I work with. So for a server called bob I just have this... alias bob="ssh bob.example.com -l pete -i /path/to/key" - then I just type bob - and I'm in! Dec 20, 2013 at 13:49
  • 2
    While it's sometimes easier to "get things done the way you already know", there are easier approaches if you setup .ssh/configs keys and hosts. This comment is directed at both the comment poster and commenter @Peter-Bagnall Dec 2, 2016 at 14:51

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.