Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

I have a situation where I need to access the same SSH host (GitHub) with two different SSH keys. This is no problem and I can set it up easily by aliasing the hostname. The problem comes when this configuration is combined with my SSH multiplexing configuration. I cannot seem to override my default ControlPath with a host-specific declaration.

Maybe this is just the way it works? Maybe it is a bug? Am I doing something wrong?

I'm on Mac 10.7 by the way.

Here is my config:

Host *
  ControlMaster auto 
  ControlPath ~/.ssh/connections/ssh-%r@%h:%p

  TCPKeepAlive yes
  ServerAliveInterval 60
  ControlPersist 1h
  User git
  IdentityFile ~/.ssh/id_rsa_X
  IdentitiesOnly yes 
  ControlPath ~/.ssh/connections/ssh-%r@%h-X:%p

  TCPKeepAlive yes
  ServerAliveInterval 60
  ControlPersist 1h

I have tinkered around a little bit, but it seems that I always get the ControlPath as specified in the Host * declaration.

ssh -T

Logs me in as the correct user using id_rsa_X, but it creates the domain socket here:


Rather than:


So later when I try to issue an SSH command using id_rsa, I get the id_rsa_X user because of connection multiplexing. In other words:

ssh -T

Gives me a hello message for the user whose key is id_rsa_X.

Any ideas?

EDIT: Response to comment by vgoff--No, it appears to be reading all my config...

$ ssh -vT
OpenSSH_5.6p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/<username>/.ssh/config
debug1: Applying options for *
debug1: Applying options for
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/<username>/.ssh/connections/" does not exist

You can see that it read all the settings and tries to use the wrong ControlPath.

share|improve this question
Is it perhaps because the Host * is being accepted as it covers all possibilities and so never sees the following listed configurations? This is what happens with globbing. – vgoff Oct 10 '13 at 8:32
up vote 5 down vote accepted

You need to move the less specific options further down in ~/.ssh/config. The Host * options are applied first and they are not overwritten by later, clashing, options, even if they are more specific. New options that were not specified in Host * will however be applied and I think that is what you saw in your log.


ssh(1) obtains configuration data from the following sources in the following order:

  1. command-line options
  2. user's configuration file (~/.ssh/config)
  3. system-wide configuration file (/etc/ssh/ssh_config)

For each parameter, the first obtained value will be used. The configuration files contain sections separated by ''Host'' specifications, and that section is only applied for hosts that match one of the patterns given in the specification. The matched host name is the one given on the command line.

Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the file, and general defaults at the end.

share|improve this answer

Your Answer


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.