IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Publickey subsystem draft posted
The generalized message format is:
UINT32 length
string type
... request specific data follows
Does the length include the 4 bytes of the length field itself? (I
don't care, but don't forget to state it either way :-)
I believe it is like both Sftp and the SSH Transport layer;
the length is not included.
Is it worth defining what should happen if a user attempts to add a
key which is already present, but with different attributes? Should
the add operation fail, or succeed and alter the key setup?
Hmmm-- since we don't have a modify, maybe we should
change add as follows:
...
string public-key-blob
bool overwrite
...
with wording like:
Clients SHOULD send the add request the first time
with overwrite false, and then, if the key turns out
to be already present, give the user the option of
overwriting the key.
We would also need to add a KEY_ALREADY_PRESENT status
message.
"restrict"
[...]
Currently defined restrictions are:
"x11"
"shell"
"exec"
"port-forward"
"reverse-forward"
What about "subsystem"? Is that worth putting in as a separate one?
Or even "subsystem:foo", for any value of foo?
Actually, the latter might get messy, since subsystem names are
permitted to contain commas by my understanding. And in practice,
anyone restricting a key would be more likely to want to forbid _all
but_ specific subsystems rather than restricting particular ones.
How about this:
Currently defined restrictions are:
"x11"
"shell"
"exec"
"port-forward"
"reverse-forward"
"subsystem"
And an additional attribute:
"subsystem"
The value is a subsystem that will be run when the key is
used. Any attempt to access an different subsystem MUST
fail. Any attempt to access other features is governed
by the "restrict" attribute.
Are there restrictions that can be expressed for
openssh keys or ssh.com keys that can't be expressed
in what is proposed?
Joseph
Home |
Main Index |
Thread Index |
Old Index