Re: tunneling and exec channel request support for SSH URIs

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

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?  Does agent forwarding need to be
specifiable through the ssh URI scheme?  What about GSS-API credential
delegation?  Will users know to check for this?  (no!)  How would we
protect users from accidentally forwarding agents/credentials to
untrusted servers?  What about specifying which userauth methods to try?

I could go on.  Frankly, I'm scared.  We could make a great many options
available in the ssh URI scheme, of that I'm sure.  But which ones
should we?

My take:

 - Agent/credential delegation -> must NOT be specifiable through URI,
   but if we must allow it then we must say that the client UI MUST
   check with the user at least once (and may cache the server as
   trusted/not-trusted thereafter).

 - Userauth method -> it's likely useful to restrict URIs to non-
   interative userauth (publickey, hostbased, and GSS-API).

    - Passwords -> danger, Will Robinson; I prefer that passwords not be
      specifiable in URIs.  (Also, passwords won't necessarily play well
      with keyboard-interactive as the server might be interested in
      more than just a password.)

 - Keyex, host auth, cipher, compression algs -> I don't see the need to
   specify these, and it'd likely be dangerous.  However, being able to
   specify sets of suites by "strength level" using a standard mechanism
   of some sort (e.g., standard names, such as FIPS-140) would be nice.

 - Channels... -> if we're going to allow for one channel to be
   specified, we should allow for multiple channels (so one URI could be
   used to setup multiple port forwards).

    - All channels should be confirmed by the UI with the user:

       - Remote commands could be dangerous to the user;
       - Port forwardings could be dangerous to the user.

    - pty? -> pty should NOT be specifiable in the URI scheme because
      what really matters is whether the client has a [virtual]
      terminal.  However, no-pty might be something we want to specify
      in a URI.  That is, whether a pty is requested should depend on
      whether the client can handle it, but it should be possible to
      request that no pty be used.

    - Port forwarding -> both directions should be allowed to be
      specified in URIs, both subject to UI confirmation.

 - 'GatewayPorts'? -> should definitely not be specifiable through URI.

 - There's surely others I'm not thinking of at the moment.  Connect
   timeouts, keepalives, ...

Nico
--