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
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.
Yes, this is very much implementation-specific as other implementations
and even future versions of OpenSSH (for all I know) might use other
means to implement subsystems, such as dynamically loaded plug-ins.
But all I ask is that the OpenSSH behaviour be allowed.
> I understand that this is
> the current OpenSSH behavior, but I believe that behavior is problematic,
> and that defining a useful, interoperable behavior is more important than
> being consistent with OpenSSH.
I agree, but this does not preclude allowing the OpenSSH behaviour
explicitly.
> 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.
Nico
--
Home |
Main Index |
Thread Index |
Old Index