Re: tunneling and exec channel request support for SSH URIs

[Thomas Anderson <terra1024%yahoo.com@localhost>]

On 4/12/2010 12:21 PM, Nicolas Williams 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?  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

The SSH URI no more has to support every single possible SSH option than the HTTP URI supports every single HTTP option.  There's no HTTP URI setting to use compression, keepalive's, to set cookies, etc, so why would you expect them in the SSH URI?  And similarly, there's no key exchange algorithm, encryption algorithm, compression algorithm, etc parameters for the HTTPS URI.

I also don't see the danger, at all, in port forwarding.  Instead of connecting to http://www.google.com you connect to ssh://domain.tld/http://google.com or whatever.  Could domain.tld be an "evil" SSH server?  Sure, but then, google.com could be subjected to MITM or users could, through social engineering, be tricked into clicking on googlephishingscam.com.  Besides, presumably users would realize that they're connecting to a new SSH server when they're asked if they want to save the server signature.  

Honestly, right now, I think PHP's SSH URI format is better than the one proposed in the current draft:

http://www.php.net/manual/en/wrappers.ssh2.php