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-b...@mindrot.org
Reporter: chr...@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
