[Bug 3570] New: Add substitution token for explicitly selected IdentityFile for ControlPath selection

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3570
           Summary: Add substitution token for explicitly selected
                    IdentityFile for ControlPath selection
           Product: Portable OpenSSH
           Version: 9.3p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: chrysn at fsfe.org

The selected IdentityFile (or a related property, eg. the public key or
a fingerprint) should be usable for the ControlPath. This would make
the IdentityFile's interaction with the command selected in the other
end's authorized_keys file safer.

I don't know the sequence of choices well enough to suggest whether
it's better to use the configured IdentityFile (leaving the
substitution empty if none was selected explicitly, and/or whatever the
agent provides is used) or the actually selected key; either would work
for me.

Concrete scenario in which I'd prefer changed behavior:

I'm sending backups over rsync to a remote host. For some time, I used
my regular key for that, so every other hour when I was not logged on
remotely, I'd get a popup from my ssh-agent (gpg-agent in my case).

At some point I created a dedicated passwordless key, which on the
server is `restrict,command=/usr/bin/rrsync -wo some-path ...`. I
created a dedicated entry in my .ssh/config (an alias for the same
HostName and same user, but with a different IdentityFile). Then I
switched my backup command from running `rsync --delete dir
host:backup_path/` to `rsync --delete dir keyless-host:` (because
rrsync changes the path semantics). As I use a global ControlPath that
includes %h-%p-%r as recommended, this could have gone awefully wrong
had I not taken care to replace the ControlPath on the new Host: It'd
have seen the existing socket, and sent the command (that was intended
to be used with a different IdentityFile) over the existing socket
opened with the regular IdentityFile.

I'm very open to suggestions as to how to address this differently, but
this is a scenario where things can easily go wrong, so I think
something should be changed. Other possible resolutions I can think of
right now include:
* State that `command=` limitations should only *limit* the semantics
of a connection, not *alter* them. (Might be clean but also
impractical, given it would suddenly render any command value that
doesn't evaluate SSH_ORIGINAL_COMMAND bad practice). This would
effectively make it rrsync's fault.
* Never share a control socket between connections for which different
identity keys were selected.

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