Re: Other comments on draft-ietf-secsh-publickey-subsystem

[Nicolas Williams <Nicolas.Williams%Sun.COM@localhost>]

On Wed, Aug 30, 2006 at 01:15:15PM -0400, Jeffrey Hutzelman wrote:
> On Wednesday, August 30, 2006 11:50:08 AM -0500 Nicolas Williams 
> <Nicolas.Williams%sun.com@localhost> wrote:
> >But the command-override wouldn't fail to speak the subsystem's
> >protocol -- typically it would be a wrapper for another program that
> >does speak that protocol.
> 
> No, because that's not how openssh works.  OpenSSH's "command" option 
> specifies a command that is used for _any_ connection authenticated by that 
> key.  That command is used for any new shell or subsystem, and it does not 
> get to know what the user requested.  That makes it kind of hard to know 
> what protocol the client wants to speak, let alone implement it.

OpenSSH sets environment variables like SSH_ORIGINAL_COMMAND, so forced
commands can find out that, gee, this is for the sftp subsystem, say.

> >>OpenSSH _can_ implement this protocol without eliminating its existing
> >>behavior and without breaking backward-compatibility, by introducing a
> >>new  keyword which has the effect specified for command-override.
> >
> >But you couldn't faithfully list pre-existing authorized_keys file
> >entries.
> 
> Sure you could, using an attribute like "command%openssh.org@localhost".
> But I would not object to adding an OPTIONAL attribute with similar 
> semantics, to allow OpenSSH to express current behavior.

True, you could do that, and you might argue that that is the better
thing to do, because then a presumably savvy client would know about
this subtle semantic difference.  I have to decide whether this makes my
concern go away.

Nico
--