split SSH and TLS keys in tsh login#45995
Merged
Conversation
github-actions
Bot
requested review from
bernardjkim,
greedy52,
tigrato and
timothyb89
github-actions
Bot
added
database-access
nklaassen
changed the title
tsh logintsh login
nklaassen
force-pushed
the
nklaassen/split-client-login
branch
from
829bd85 to
c220459
Compare
nklaassen
force-pushed
the
nklaassen/split-ssoLogin
branch
from
cd74d63 to
4c40ee2
Compare
nklaassen
force-pushed
the
nklaassen/split-client-login
branch
from
c220459 to
2f52a3c
Compare
nklaassen
force-pushed
the
nklaassen/split-client-login
branch
2 times, most recently
from
1f27f95 to
d829235
Compare
nklaassen
changed the base branch from
master
to
nklaassen/cryptosuite-refactor
Contributor
Author
|
I pulled out #46362 to make this PR slightly smaller. This is also no longer a draft, but the github email subject still says [draft] since that was in the original title, I'm hoping that leaving this comment will make github reevaluate that and change the email subject edit: apparently not :( |
nklaassen
force-pushed
the
nklaassen/split-client-login
branch
from
d829235 to
c6038e6
Compare
Contributor
Author
|
friendly ping @bernardjkim @greedy52 @tigrato @timothyb89 |
rosstimothy
approved these changes
Sep 10, 2024
bernardjkim
approved these changes
Sep 10, 2024
public-teleport-github-review-bot
Bot
removed the request for review
from timothyb89
Co-authored-by: Bernard Kim <bernard@goteleport.com>
nklaassen
force-pushed
the
nklaassen/split-client-login
branch
from
4d5df21 to
175b730
Compare
Instead of waiting for all 25 test keys before returning a single one, tests can now make use of the first precomputed test key as soon as it's ready. In local testing with this change, the first key is ready after ~75ms vs >350ms on master.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR splits all client-side generated SSH and TLS keys used in
tsh. The end result is that if you setcluster_auth_preference.spec.signature_algorithm_suitetobalanced-v1, ontsh loginyou will get an Ed25519 SSH key and an ECDSA P-256 TLS key, each saved in its own file under ~/.tsh with its matching certificate. Those split keys will then be used as required for all TLS and SSH operations.If
signature_algorithm_suiteis unset orlegacy, you will continue to get RSA keys. These will still be stored separately in their own files under ~/.tsh, but they are still the same key. Hardware keys will also continue to use a single key with the PEM reference stored in separate files.The exceptions to the key split are anything that uses an identity file. This includes:
tsh login -o <file> [--format file]tctl auth sign --format fileThese all continue to use a single key for both SSH and TLS, because the identity file format only support storage of a single key. This is backward-compatible, new versions can read old identity files, and old versions can read identity files generated by new versions.
I apologize for the size of this PR. I've been trying to split things up, but at a certain point everything became too entangled with
client.KeyRing.PrivateKey. I basically made this PR by splitting that intoSSHPrivateKeyandTLSPrivateKeyand then fixing everything that broke. But I'm not doing anything too interesting in here, almost all changes are client side and just updating everything to pass the right keys around.Part of RFD 136
changelog: Added support for Ed25519 SSH keys and ECDSA TLS keys in CLI clients