Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Like most sysadmins I use openssh all the time. I have about a dozen ssh keys, I like to have a different ssh key for each host. However this causes a problem when I am connecting to a host for the first time, and all I have is a password. I want to just connect to the host using a password, no ssh key in this case. However the ssh client will offer all the public keys in my ~/.ssh/ (I know this from looking at the output of ssh -v). Since I have so many, I will get disconnected for too many authentication failures.

Is there some way to tell my ssh client to not offer all the ssh keys?

share|improve this question
2  
Why would you want a different key for each host? Keys may as well be shared across hosts within a single administrative domain. Obviously, you'd use one key for your work machines and another for your private machines, but what's the logic behind using a seperate key for each machine at work? – Alex Holst May 8 '10 at 18:14
    
@AlexHolst I'm using many keys. I have a default one encrypted (which require me to enter a password) for internal infrastructure. I have another one not encrypted (without a password) which I use for one specific service where I could not use an agent nor wanted to type every minute the password. I have others for connections which are not part of our internal infrastructure. It is good practice, because even though it should be pretty hard for someone to recover the private key from the public key, it can be done. e.g. the Debian openssh bug some years ago... – Huygens Jul 15 '15 at 21:05
    
@Huygens I'd love to see your risk analysis document that resulted in the conclusion you need to use several SSH keys but having a clear text keys is fine. Can you post a link? – Alex Holst Jul 17 '15 at 16:05
    
@AlexHolst you don't have to be so "direct". First of all my answer was about reasons for having multiple key pairs. I think I gave you several. After, we all have to deal with quirks and what not. I have a test system for which I cannot use an app which is tunneling data via SSH without being prompted continuously for the key password making the software not usable. It seems to be a bug due to versions incompatibility or what not. I get email notification for any SSH login, and I'm the only one login to that box. So the risk is acceptable. – Huygens Jul 20 '15 at 5:38
up vote 9 down vote accepted

This is expected behaviour according to the man page of ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Basically, specifying IdentityFiles just adds keys to a current list the SSH agent already presented to the client.

Try overriding this behaviour with this at the bottom of your .ssh/config file:

Host *
  IdentitiesOnly yes

You can also override this setting on the host level, e.g.:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes
share|improve this answer

Following James Sneeringer's solution, you might just want to set an ssh_config along the lines of:

Host *.mycompany.com
  IdentityFile .ssh/id_dsa_mycompany_main

Host *.mycustomer.com
  IdentityFile .ssh/id_dsa_mycustomer

Host *
  RSAAuthentication no #this should be up top, avoid ssh1 at all costs
  PubkeyAuthentication no

If you connect with a particular key to many machines not in a common domain, consider giving them all CNAMEs in your own DNS. I do this with all customer systems.

share|improve this answer

Although others have hinted at this with configuration-based solutions, it's probably worth pointing out that you can easily do this one-time-only on the command line with:

ssh -o 'PubkeyAuthentication no' myhostname.mydomain
share|improve this answer
    
Perfect .. THE solution IMHO – drAlberT Oct 21 '14 at 16:38

Similar to user23413's solution, you can disable public key authentication altogether for a particular host (or wildcard pattern):

Host *.example.org
RSAAuthentication no        # SSHv1
PubkeyAuthentication no     # SSHv2
share|improve this answer

If you point to a particular key file with ssh -i /path/to/key it'll only use that one even if others are loaded into the agent, and you won't be prompted for the password. You can also edit you ~/.ssh/config and ad something like this...

Host foo.example.com
IdentityFile .ssh/id_rsa_foo.example.com

you can also do...

Host *.example.org
IdentityFile .ssh/id_rsa_example.org

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.