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@xxxxxxxxxxxxxxxxx Destination-constraint: scylla.example.org Destination-constraint: scylla.example.org>medea@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
