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