SSH Pubkeys - Add Descriptive Metadata when adding public keys

[strazto]

TL;DR

Add a mandatory description field where intializing public keys.
I advise taking inspiration GitHub's view for SSH keys, as described at the end.

Problem

When managing SSH public keys for a given user, we're able to input any valid SSH pubkey, including one with a comment field, for example

Input pubkey

# The input key
cat id.warpgate.ed25519.pub

yields

ssh-ed25519 <key_here> MacBook_2023

Running the following:

ssh-keygen -l -f  id.warpgate.ed25519.pub

yields

256 SHA256:<key_fingerprint> MacBook_2023 (ED25519)

However, if we paste the value of the above key into warpgate as a user key and save it, the comment part is stripped out

Saved pubkey

When we view the stored key, we see only the following:

ssh-ed25519 <key_here>

The comment has been removed

If we take the value of the saved pubkey out

(copy it out of warpgate's UI, paste it into a new file, and get the fingerprint),

there's no comment

ssh-keygen -l -f id.pasted.ed25519.pub

256 SHA256:<key_fingerprint> no comment (ED25519)

This lack of descriptive metadata makes management of public keys via the UI relatively challenging, as for a list of keys associated with a user, it's quite challenging to ascertain which device the key is for, and the purpose of that key.

Lack of metadata in the current key management view

Regardless of whether a key's metadata comes from the ssh key's comment, or is given as a field in warpgate itself, managing public keys becomes challenging and confusing when a given account has 2 or more (let alone several or dozens which might be possible in some use-cases)

The current view

The following screenshot highlights this:

My account has three keys, imagine one of the keys corresponds to a dev laptop that has been lost or stolen.

How can I ascertain which key corresponds to what device / app, and revoke it?

Indeed, by the very design of public / private key pairs, to deduce which pubkey corresponds to what private key, we'd have to test the rest of our other private keys against each key shown here (or if our pubkeys are stored somewhere with more context, such as next to their private keys, or with a descriptive comment, we can check whether any of the key values are the same).

A more usable view

Compare this with a tool such as Github:

Github's view has a few distinctions in what extra information it surfaces about the key:

1. It gives us a human readable key description.
   • This is a required field when initializing the public key, and is given as a completely separate field from the key
   • This context is vital in key management
2. It shows us when the key was last used
   • This is also very useful in determining whether the key is actually part of some automation or active user.

Github's view also has the distinction that it does not provide read access** for pubkeys after their creation, only their:

• Description,
• Fingerprint
• Last used,
• the delete operation.

Personally, I am not advocating for adoption of this particular behaviour, GitHub likely has their own reasons for this, but I view it as separate to the issue at hand.