Hi. As you can see from bug #2318 which is very loosely related to this one, I was recently experimenting with control channel muxing. #2318 is about collisions, when the socket is placed into locations writeable by multiple users - i.e. %u was "missing" from %C and the suggestion in the manpage. Now I thought whether there would be other similar cases, or in other words - what makes a ssh connection (with all it's settings and properties) unique? Currently the %X symbols and the choice of %C and the suggestion in tha manpage only deal with source user/host, and target user/host/original-host/port. What's IMHO missing though, is the Identity/Certificate, used in case of pubkey authentication (or similar). I can use the same source host/user and connect with ssh to the same target host/port/user/etc. and yet get completely different connections, because the used Identity may be different. On the server side, different Identities (i.e. keys) may lead to different connections (depending on what's set in ~/.ssh/authorized_keys (e.g. things like command= and so on). So: - ssh -p 22 foo@example.org -i ~/.ssh/load.rsa could e.g. lead example.org to give back the system load (restricted by command=) - ssh -p 22 foo@example.org -i ~/.ssh/id_rsa could be the normal login ID. Obviously, when one uses control channel muxing with a "generic" default value for the ControlPath, this leads to troubles, since a generic setting would be something like e.g. "~/.ssh/ control-mux/%r@%h:%p" which is however the same for both. Therefore, I think it would be nice to have another symbol, e.g. %i, which is a hash of the precious part of the identity. E.g. for an ssh key, that would be everything but the comment. Obviously, %C and the manpage suggestions should probably be extended for that new symbol as well,... People using only one key for the same connection won't be hurt by this, but apart from that we should get a %C, which really enables us to use this as a default path for all cases that might arise - without any name collisions or unexpected/undesired connections effects. Cheers, Chris.
I don't think this is particularly useful - you could achieve your goal using Host sections in ssh_config and there are a few corner cases that would make this fiddly and fragile if implemented. E.g. it might have some use if there was only one key supplied, but it is confusing if multiple keys are available. ssh wouldn't know which one would be successful at startup and would need to remember which and pass it through to the mux socket creation later. Worse, it's possible to authenticate using multiple public keys. Which should be included in this case? There are too many caveats and corner cases to justify this change's limited usefulness, sorry.
Close all resolved bugs after 7.3p1 release