openssh bugs - Nov 2014 - [Bug 2321] New: please add a symbol to ControlPath, which expands to (a hash of) the identity

https://bugzilla.mindrot.org/show_bug.cgi?id=2321

            Bug ID: 2321
           Summary: please add a symbol to ControlPath, which expands to
                    (a hash of) the identity
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.net

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 at 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 at 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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2321

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |djm at mindrot.org
         Resolution|---                         |WONTFIX

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2321

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after 7.3p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.