Re: tunneling and exec channel request support for SSH URIs

[nisse%lysator.liu.se@localhost (Niels Möller)]

Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:

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

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.