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