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