IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Jeffrey Hutzelman wrote:


On Wednesday, August 30, 2006 11:50:08 AM -0500 Nicolas Williams <Nicolas.Williams%sun.com@localhost> wrote:

On Wed, Aug 30, 2006 at 12:37:55PM -0400, Jeffrey Hutzelman wrote:
> Therefore I think the fair thing to do would be to either allow the
> 'command-override' command to override subsystem commands also

I don't think so.

Subsystems are not the same as shells.  A subsystem name is essentially
a  protocol constant used to request a particular service; it is not a
command.  It's appropriate to limit what subsystems may be used, but not
to  replace a subsystem with a connection to a random program that does
not  speak the protocol defined for that subsystem.

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

It doesn't seem inappropriate to use "@openssh.org" to express
an openssh compatibility option.

In the normal course of events, I wouldn't be opposed to adding
a standard attribute to the draft, but I'm worried that something
like that would require us to redo last-call?  And given the
deadline we are operating under, I suspect this is not a winning
option.

Thanks,

Joseph




Home | Main Index | Thread Index | Old Index