Jeffrey Hutzelman <jhutz%cmu.edu@localhost> wrote:
- We _do_ want to be able to have URI's that refer to connections
to arbitrary subsystems. Some subsystems may be more useful to access
in this way than others.
[...]
- [...] probably we should not allow SSH URI's that direct
the user to execute a particular command on a remote SSH server. That
sounds exceedingly dangerous.
I'm unconvinced that these two points are really consistent with
each other. If I want to set up a custom service on a given SSH
server, I might find it inconvenient to invent a new subsystem name,
or to set up a special account whose shell is the service program,
so I might prefer to provide service users with a command to run.
Drawing a hard dividing line between "subsystem" and "exec" seems
like the wrong answer to me.
The real danger is URIs which combine a specific command with the
user's _personal_ credentials. There's no danger in 'ssh to this
specialist service machine, log in as specialist-service, and run
specialist-service-command', but there is danger in 'ssh to this
server you had an account on anyway, implicitly log in as yourself
due to already having an SSH agent active and the URI not specifying
a username to override your own, and run "rm -rf *"'. So perhaps the
right answer is to constrain both command and general-subsystem
specifications to the case in which full authentication credentials
(e.g. username _and_ password) are also provided in the URI _and
authentication with those credentials succeeds_?