The previous functionality provided two checkboxes: one for requesting
that the TOTP key be cleared, and another for directly managing whether
the TOTP key has been confirmed. This is confusing as checkboxes
normally represent state, but the "reset" checkbox here is representing
an action.
Instead, both checkboxes should represent state: whether the key has
been generated and whether the generated key has been confirmed.
Besides restoring historically-provided functionality, the ID generated
by the database for connection history records is needed to generate a
deterministic UUID that can be injected into connection configurations
with ${HISTORY_UUID}. Having such a token allows session recordings to
be given names that can be reliably matched with history records.
An SSH server record in KSM has an associated "KeyPair" field, but this
field need not be set. If unset, the current logic ignores the rest of
the record and assumes there is no private key at all. Instead, the
standard fallbacks of locating an attached PEM file, locating an
alternative password field, etc. should be used.
When retrieving a contextual field like "passphrase", which does not
have a typed representation different from "password" or "hidden", the
contexts where the field's identity is truly known should be preferred
("password" field of a record with a "keypair" field, which MUST be the
key passphrase). When venturing outside well-known contexts, custom
fields should be preferred when their standard counterparts would
already have well-established meanings that differ from the requested
secret (again: "password" of a record with "keypair").
If this is not done, things like retrieving the private key from a
"Login" record fail, as one of the possible storage mechanisms for a
private key is a hidden or password field, which pulls the user's
password instead of their key. In this case, the correct behavior is
to pull the typed value ("keypair") if available, and use custom fields
ONLY otherwise, as those fields have labels that can establish context.
In no other case would it be reliable to assume that a hidden/password
field actually contains a private key.
Doing otherwise would mean that a particular user would never be able
to be associated with a specific password/key by their username if they
have any explicit server-specific account.
Niubbo75
James Muehlner
Mike Jumper
Virtually Nick