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