Re: tunneling and exec channel request support for SSH URIs

[Jeffrey Hutzelman <[e-mail]>]

--On Monday, April 12, 2010 12:21:13 PM -0500 Nicolas Williams 
<[e-mail]> 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://[e-mail]/exec:ls%20-la
>>
>> ...or...
>>
>> ssh://[e-mail]/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.

IMHO...

- We _do_ want to be able to specify a username, and yes, even a password.
  Remember, you're not expressing the password of the user following the
  URI; you're expressing the password needed to access the resource.  It
  is common to set up a resource which requires a username and password,
  and then advertise the username and password to a limited audience.

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

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

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

- 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.
  This type of tunnel is a common use of SSH, and makes sense both as a
  service and as a URI resource.  It poses no threat to the user of such
  a URI, provided the selection of a port on the client end is up to the
  SSH client and _not_ contained in the URI, and that the SSH client takes
  the usual precautions for such tunnels.

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

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

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

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

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

-- Jeff