Subject: tunneling and exec channel request support for SSH URIs

From: Jim Wigginton <[email-masked]>
Date: Sun, 4 Apr 2010 21:56:01 -0700

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://[email-masked]/exec:ls%20-la

...or...

ssh://[email-masked]/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.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 Apr 2010 12:21:13 -0500

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Apr 2010 14:15:44 -0400

--On Monday, April 12, 2010 12:21:13 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> 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

---

From: [email-masked] (Niels Möller)
Date: Wed, 14 Apr 2010 10:49:08 +0200

>  should not be subject to override.

All of this makes sense to me.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: Simon Tatham <[email-masked]>
Date: Wed, 14 Apr 2010 11:04:26 +0100

>   to arbitrary subsystems.  Some subsystems may be more useful to access
[...]
> - [...] probably we should not allow SSH URI's that direct

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"
<[email-masked]>     - Index, Borland Pascal Language Guide

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Apr 2010 10:33:50 -0500

On Tue, Apr 13, 2010 at 02:15:44PM -0400, Jeffrey Hutzelman wrote:
> 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.

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

Yes to the first, grumble to the latter.

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

>  to arbitrary subsystems.  Some subsystems may be more useful to access

Yes.

>  accessed via SFTP.  However, this probably wants to be a separate

Yes, and yes.

>  allow the SSH client to connect to services on the SSH server's network.

Yes.

>  allow the SSH server to connect to services on the SSH client's network.

Maybe.  See below.

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

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

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

>  should not be subject to override.

Yes.  This was the gist of my initial reply.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 19 Apr 2010 18:59:00 -0400

> authentication with those credentials succeeds_?

Yes, I think that's closer to the mark.  On the other hand, I do think it 
should be possible to write a URI that refers to an SFTP service accessed 
using the user's credentials.  I suppose to make this determination for a 
subsystem, one needs to know what the subsystem does, which suggets that 
such cases require a separate URI scheme or at least further specification 
beyond the scope of the present document.

-- Jeff

---

From: [email-masked] (Niels Möller)
Date: Tue, 20 Apr 2010 11:30:33 +0200

>> user's _personal_ credentials.

> Yes, I think that's closer to the mark.  On the other hand, I do think
> it should be possible to write a URI that refers to an SFTP service
> accessed using the user's credentials.

I think the relevant distinction is that we don't want URI:s that
specify *destructive* operations using the user's credentials. Creating
an interactive shell is not destructive (unless the user's login shell
is set to something interesting), and reading a file over sftp also is
not.

But executing a command may or may not be destructive. And there's no
easy way to make the distinction (like GET vs POST in HTTP, if only
people were using them the right way...).

I haven't made up my mind on ssh uri:s (and the topic is on the
periphery of my personal interests), but it seems the safest option is
to not have URIs specifying execution of commands at all.

Specifying an uri to start an arbitrary subsystem may still be ok. It is
different from executing a command, if we are willing to assume that
merely *starting* the subsystem does not imply any destructive
operations, just like for starting an interactive shell. To actually
*do* somthing using that subsystem should most likely use a separate uri
scheme.

Regards,
/Niels

---

From: Simon Tatham <[email-masked]>
Date: Tue, 20 Apr 2010 10:46:10 +0100

Jeffrey Hutzelman <[email-masked]> wrote:

> subsystem, one needs to know what the subsystem does,

Yes. SFTP could reasonably be an exception to the general principle
I suggested, based on specific knowledge that SFTP in particular is
a subsystem which won't do anything destructive just from being
invoked - it would have to be specifically instructed by the user to
delete or modify files for anything dangerous to occur.

But really, an SFTP URI and an SSH URI citing subsystem "sftp" are
not semantically the same anyway. The latter, if it is to be treated
consistently with URIs citing a command, merely tells a basic SSH
client what exec/subsystem request to send, so that the user would
be presented with raw access to the SFTP service, which isn't very
useful at all. The former also indicates that a different client
program (or the same client program in a different mode, according
to taste) should be run, so that the user gets a thing that looks
like a filesystem browser.
-- 
Simon Tatham         "The difference between theory and practice is
<[email-masked]>    that, in theory, there is no difference."