Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose --compat certificate flag to Web users #1542

Closed
kontsevoy opened this issue Jan 4, 2018 · 4 comments
Closed

Expose --compat certificate flag to Web users #1542

kontsevoy opened this issue Jan 4, 2018 · 4 comments
Assignees

Comments

@kontsevoy
Copy link
Contributor

kontsevoy commented Jan 4, 2018

Problem

Older versions of OpenSSH have a bug which prevents them from consuming SSH certificates that contain metadata. For this purpose, tsh login uses --compat flag to issue certificates that trade functionality (cross-cluster trust) for compatibility with older sshd.

But when a Web UI user logs in, there's no equivalent to --compat option. This leads to web users not having access to legacy sshd hosts.

Solution

TBD [by @klizhentas ] But one challenge I see is that it would be nice to make this work for open source users too, i.e. adding a role-hosted flag is not ideal.

@kontsevoy kontsevoy added this to the 2.4.1 milestone Jan 4, 2018
@klizhentas klizhentas assigned russjones and unassigned klizhentas Jan 4, 2018
@russjones
Copy link
Contributor

We can extend the functionality we currently have in the --compatibility flag by adding compatibility to options in the role.

kind: role
version: v3
metadata:
  name: admin
spec:
  ...
  options:
    compatibility: ["oldssh"|"off"]

By default roles would have compatibility: off unless compatibility: oldssh is explicitly specified in the role. This would work well with both Teleport and Enterprise because by default they would have new style certificates.

The Web UI would always use the compatibility value in the role, but with tsh if --compatibility is set, we would override whatever value is in the role with what is passed in giving the user more control over how the certificate is generated.

This would be backward compatible for existing users but also allow users to update how the Web UI requests certificates.

@kontsevoy @klizhentas What do you think?

@klizhentas
Copy link
Contributor

this looks good to me

@kontsevoy
Copy link
Contributor Author

kontsevoy commented Jan 5, 2018

How about:

options:
   cert_format: ["compat" | "standard"]  

This way in the docs I can say cert_format: compat is equivalent to tsh login --compat. Same words, learn two bits at once.

@russjones
Copy link
Contributor

Talked about this with @kontsevoy offline, we'll change "compat" to "oldssh" so we can support multiple compatibility modes in the future.

options:
   cert_format: ["oldssh" | "standard"]  

tsh will similarly support --cert-format=["oldssh" | "standard"] as the new supported way to pick the certificate format, but will continue to support --compat=oldssh as a hidden option for backward compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants