Please help test recent changes

[Fabian Stelzer]

On 10.01.2022 08:07, Nico Kadel-Garcia wrote:
>On Mon, Jan 10, 2022 at 7:51 AM Fabian Stelzer <fs at gigacodes.de> wrote:
>>
>> On 09.01.2022 15:56, Ángel wrote:
>> >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 think the trend is (and should be) going towards keeping private keys in
>> hardware tokens and no longer in files on disk. FIDO, PIV Smartcards, GPG
>> Smartcards, HSMs, TPMs all allow for very safe private key storage. If you
>> allow these constraints to be specified in a config file either referenced
>> under a key fingerprint (probably easiest):
>
>There are many trends Many, many tools and systems rely on old
>features and would break very badly indeed if support for private keys
>is lost. And there are some features of locally stured keys, such as
>using multiple keys simultaneously to provide signed keys such as
>those supported by Hashicorp Vault, that do not work well with other
>key storage formats
>(https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates
>)

I'm not suggesting loosing support for locally stored keys. I only would 
like to encourage a feature to store these key constraints to be compatible 
with both variants of private key storage. (which a separate config 
file/header would be)

I don't have an example of using multiple private keys for a signature, but 
I don't see any reason why those should not also work with key stored in 
hardware. If the current tool works with an ssh-agent then hardware keys 
should work just as well.

>
>> Key SHA:256INGERPRINT:
>> DestinationConstraint: perseus at cetus.example.org
>> DestinationConstraint: scylla.example.org
>> DestinationConstraint:
>> scylla.example.org>medea at charybdis.example.orgscylla.example.org
>>
>> Or maybe under a Host section:
>> Host cetus.example.org
>>      ForwardAgent yes
>>      ForwardKey SHA256:xxx
>>      ForwardKeyConstraint scylla.example.org
>>
>> then you can still auto load these instead of writing ssh-add scripts. I
>> think most ssh users who would use this feature probably already have some
>> mechanism of managing their .ssh/config.
>
>For keys such as signed SSH certificates, I'd want to support
>providing multiple forwarding keys. I'm not working with those
>personally right now, but the linking of only single keyes to SSH
>access inerferes with the otherwise supported signed key access.

These config blocks were just an example of how this could look like.
Both could allow multiple keys if needed. (Maybe you could even constrain to 
all keys signed by CA XXX).