On 1/6/22, 18:29, "Damien Miller" <djm at mindrot.org> wrote:
On Fri, 7 Jan 2022, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:
> Hi Damien,
>
> The restricted agent keys functionality sounds really interesting.
> Are there any plans to support embedding the restrictions in the keys
> themselves at some point? That would make this much easier to use, but
> it would require extending the key format and adding the appropriate
> parsing in ssh-agent or ssh-add.
I hadn't considered that before - how would it envision it working?
Yes, the key format would require extension and that isn't a trivial
change because of backwards-compatibility :(
-d
I haven't given the details much thought and haven't delved into the
OpenSSH code in quite a while, so my idea is rather sketchy at this point.
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
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. > > -- > IainGood 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