Re: tunneling and exec channel request support for SSH URIs

[Simon Tatham <anakin%pobox.com@localhost>]

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_?
-- 
Simon Tatham         "infinite loop _see_ loop, infinite"
<anakin%pobox.com@localhost>     - Index, Borland Pascal Language Guide