Re: tunneling and exec channel request support for SSH URIs

[Nicolas Williams <Nicolas.Williams%oracle.com@localhost>]

On Tue, Apr 13, 2010 at 02:15:44PM -0400, Jeffrey Hutzelman wrote:
> --On Monday, April 12, 2010 12:21:13 PM -0500 Nicolas Williams
> <Nicolas.Williams%oracle.com@localhost> wrote:
> 
> >On Sun, Apr 04, 2010 at 09:56:01PM -0700, Jim Wigginton wrote:
> >>I was thinking about SSH URI's some and I think it'd be neat if the
> >>draft for SSH URI's supported tunneling and exec style channel
> >>requests.  eg.
> >>
> >>ssh://user%host.example.com@localhost/exec:ls%20-la
> >>
> >>...or...
> >>
> >>ssh://user%host.example.com@localhost/tunnel:www.google.com:80
> >>
> >>As is, the only thing that SSH URI's, as defined in the draft
> >>(draft-ietf-secsh-scp-sftp-ssh-uri-04), really support, it seems, are
> >>retrieving files via SFTP and opening interactive shells.  And
> >>although that, I suppose, has its uses, I think SSH URI's could be
> >>made a lot more versatile by adding support for the above.
> >
> >Good point.  But where should we stop?
> 
> A URI should identify a resource.  That is, it should identify some
> particular object or service, such as an interactive shell, a file
> in SFTP (arguably this should be a distinct URI scheme), or some
> other subsystem. It does not need to and probably should not be
> capable of expressing configuration of parameters that control how
> we talk to the ssh server, such as algorithm selection.

Is an interactive shell an identifiable resource?  IMO, that's
borderline, but because it'd be useful I think it should be supported.

> IMHO...
> 
> - We _do_ want to be able to specify a username, and yes, even a password.

Yes to the first, grumble to the latter.

> - We _do_ want to be able to have URI's that refer to interactive
>  shells, if only because this is the "main" service SSH provides.

Yes, but do we want to specify that a pty is needed?  To me that follows
client context and isn't part of the resource being identified.
Alternatively: indicate in the URI that a terminal is required in order
to access the resource.

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

Yes.

> - We _do_ want to be able to have URI's that refer to specific files
>  accessed via SFTP.  However, this probably wants to be a separate
>  URI scheme.

Yes, and yes.

> - We _do_ want to be able to have URI's that establish tunnels which
>  allow the SSH client to connect to services on the SSH server's network.

Yes.

> - We do _not_ want to be able to have URI's that establish tunnels which
>  allow the SSH server to connect to services on the SSH client's network.

Maybe.  See below.

> - We do _not_ want URI's to be able to express preferences for algorithm
>  selection in any form.  This would amount to allowing the provider of a
>  URI to override the client's security policy, which is a bad idea.

I don't agree with the rationale: client local security policy should
always trump whatever's in the URI.  The ability to specify algs in the
URI does not make that necessarily untrue.  But I agree with the
sentiment (after all, the client and server can and will negotiate;
attempting to preempt the negotiation won't).

> - A user agent may wish to restrict what userauth methods can be used,
>  based on its ability to handle user interaction or on local security
>  policy.  In fact, we probably should offer advice about taking care
>  with the use of non-interactive authentication methods, lest an attacker
>  trick a user into issuing a command to some service.

How can you use, say, pubkey userauth to "trick a user into issuing a
command to some service" other than the service identified by the URI?

> - In a similar vein, 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 tend to agree with this and the "no local port forwardings", but also
think that client UIs can take care of warning the user, or even
outright fobidding access to such URIs.  Having a way to name an
arbitrary remote command execution could be useful in some contexts.
However, if it were so useful that most users would disable the
warnings, then I think we'd be better off not specifying a way to create
such URIs in the first place.

> - And, an SSH URI should not be able to control behaviors like agent
>  forwarding, which again are a matter of client security policy and
>  should not be subject to override.

Yes.  This was the gist of my initial reply.

Nico
--