Please help test recent changes

[Ángel]

On 2022-01-07 at 18:51 +0000, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
> What we would want is some way of associating the restrictions with a
> key so that they are automatically applied when the key is loaded
> into the agent, either by ssh-add or when triggered by
> AddKeysToAgent. That would either mean adding the restrictions to the
> private key, or adding another file that is associated with the key
> which contains the restrictions. The latter would be easier to
> implement from a backwards-compatibility standpoint, but I'm not
> particularly happy about adding another file type.
> 
> The file containing the options would be assumed to be in the same
> directory as the private key, and would be formed by adding an
> extension such as ".opts" or ".cfg" to the name of the private key.
> 
> I don't have any specific ideas as to how to express the
> restrictions, but we would probably want one line for each allowed
> path. Also, the ssh-add command line should be able to override the
> restrictions. Perhaps the syntax might be something like:
> 
>         AllowedPath: foo.example.com > bar.example.com ...
> 
> Alternatively, perhaps it would be possible to include the
> restrictions as plain-text in the private key, before the "-----
> BEGIN" line. That assumes that any text outside of the BEGIN ... END
> sequence is ignored by existing implementations.
> 
> As an aside, either approach should allow for adding support for
> other kinds of restrictions. For example, it might be convenient to
> add a Timeout parameter that would correspond to the -t option with
> ssh-add.
> 
> --
> Iain

Good point. A key should probably always have the same restrictions
(after some testing to get those right).

I would include them as armor headers, though:

-----BEGIN ALGO PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,AABBCC...
Destination-constraint: perseus at cetus.example.org
Destination-constraint: scylla.example.org
Destination-constraint: scylla.example.org>medea at charybdis.example.orgscylla.example.org

SGVsbG8gd29ybGQhCg...


I don't think backwards compatibility of the private key is a concern
here. You already need an updated openssh stack to make use of the new
features, and copying private keys between systems isn't generally a
good idea (it's better to have a different key per source host).

Nonetheless, by placing these headers at the end, they seem to be
ignored by prior ssh-add versions (placing them before Proc-Type or
DEK-Info cause "invalid format" errors).


Best regards