Re: Publickey subsystem draft posted

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

> This doesn't match the "command" attribute, which starts the command 
> itself.  Then again, I'm unhappy with that aspect of the "command" 
> attribute's behaviour - it raises questions such as When does it start 
> the command?, Does it wait for the client to request a pty or run the 
> command without one?, etc.  Maybe change "command" to specify a command 
> which the user's allowed to execute.  Ideally, change it to specify more 
> than one command, but in that case, I'm not sure what could be used as a 
> separator.  Maybe allow for more than one command attribute to be set?

If I'm not mistaken openssh allows a command to be associated
with the key?  I believe ssh.com and f-secure do as well.

Does any one know what their behavior is?  I was thinking that
whenever one of exec / shell where issued, the command specified
by the publickey was substituted.  But maybe that isn't the case.

If we really wanted allowed commands, and I'm not sure we do,
the attrib-value string could be:

string attrib-value
	uint32 command-count
	string command[1]
	string command[2]
	string command[...]
	string command[command-count]

But, how closely doe the user have to match the command?
Exactly?  Just the first argument?

I'm worried about over complexifying things... sure we could do
it, but one of the goals of the subsystem is to be easy to
implement.

Maybe we should rename command to command-override and
specify that it forces either the 'exec' or the 'shell'
session channel requests to act as if the 'exec' request
had been issued with the given command.

- Joseph