Adding a host-certificate string to allow clients to authenticate the host.
SSH host certificates are digital documents that verify the identity of an SSH server to a client. They are signed by a trusted Certificate Authority (CA) and include information like the server's public key, its hostname, and an expiration date. This allows clients to securely connect to SSH servers without needing to rely on static host keys, streamlining authentication and enhancing security.
Should this follow our pattern elsewhere where we point to a certificate id? (example)
Do we need these other files/leafs?
Host Certificate - the signature made for the Host Public Key using the Certificate Authority. (presumably this is the host-certificate leaf added in this PR so far)
Certificate public key - the public component of the certificate authority
Host Public Key - the actual key that the SSH daemon uses to identify itself to the clients
/gcbrun
No major YANG version changes in commit e1a4f9463051b853b30388c12cf1a0f024f083e7
Do we need these other files/leafs?
Host Certificate - the signature made for the Host Public Key using the Certificate Authority. (presumably this is the
host-certificateleaf added in this PR so far)Certificate public key - the public component of the certificate authority
Host Public Key - the actual key that the SSH daemon uses to identify itself to the clients
How about authorized principles and mappings to users? There are already implementations that can be referenced here (Note: this also would need to not assume gNSI)
Yes, if we would like to have parity between gnsi.Credentialz capabilities and the yang model it would be more consistent to additionally be able to set host key (both private and public) as well as authorized principles and hiba and glome and trust bundles. This PR is minimal and strategic as some optical vendors would not be able to support gnsi for a long time, but they do have gnmi Set capabilities and this leaf would be helpful.
/gcbrun
/gcbrun
/gcbrun
/gcbrun
Discussed at the OC Operators Meeting Dec 2nd - Seems the leaves are being added under /system/ssh-server/config, can we add a diff of the tree before/after this PR in the first comment?
Additionally, it seems important to have the certificate expiration leaf exposed here, as well? I know that we're trying to keep it minimal here, but it seems beneficial to add here. (Similar to this leaf.)
(The information would also be in the text, but parsing text seems like an unpleasant requirement to get the expiration information.)