Auth sign with a long ttl doesn't seem to work.

[stanchan]

What happened:
When generating a cert for automation users, the certs expire in a day.
$ tctl auth sign --ttl=87600h --user=jenkins --out=jenkins.pem

Get the following with a re-login request after 24 hours:
WARNING: the certificate has expired on 2018-03-03 05:24:03 +0000 UTC

What you expected to happen:
Should expire based on ttl value.

How to reproduce it (as minimally and precisely as possible):
The following should not prompt you to login.
$ tsh -i ~/.ssh/id_rsa --proxy=teleport-proxy:3080 --user=jenkins ssh targethost

Environment:

• Teleport version (use teleport version): 2.4.2
• Tsh version (use tsh version): 2.4.2
• OS (e.g. from /etc/os-release): debian 9

[klizhentas]

cert TTL is adjusted to max session TTL defined in role, for OSS builtin role that would be 24hours

[klizhentas]

I recommend not to issue the long lived cert, but instead rotate the short lived one and re-publish it

[stanchan]

This makes it pretty hard to use teleport as a replacement for a ssh server in a lot of use cases. Also, the documentation would be incorrect as that is currently what tctl is capable of creating these long duration keys.

[klizhentas]

can you give me examples of those use cases? I'm really curious, would like to learn more about them, may be I can give some advice.

[stanchan]

One example would be having ephemeral Jenkins build slaves instances spun up with a Mesos scheduler, that would have a jenkins user ssh key stored in the keystore (manual process). The job would inject the keys into the environment of the build slave, perform a build and deploy a set of scripts to a target instance using ssh. Using teleport to replace ssh in this scenario would be a possible use case.

Another possible use case would be to have an AWX/Ansible task runner deployed in a K8s cluster, with the key stored in an Ansible Vault stored in git and the encryption key stored on the master. A docker instance of the task runner would be deployed into the pod, join the cluster, pull a task from the queue, inject the decryption key into the instance, pull the Ansible playbook/roles/vault from git and decrypt the ssh keys and execute the playbook against a set of targets hosts.

Is there a way to generate the keys without 2fa and without being on the auth server?

[klizhentas]

The nice thing about SSH certs is that private keys don't really matter as much as with public private key SSH not using certs. This means you don't really need to store private key of the SSH key any more, and simply generate on demand both private/public keypair and sign it for the duration of the process (a couple of minutes or hours), then throw the whole thing away.

It is possible to talk to auth server just like any other HTTPS API and generate certs with proper SSH principals, here is an example of how to connect to the auth server in 2.5.0 release:

https://github.com/gravitational/teleport/tree/master/examples/go-client

In all your examples you can generate the ephemeral credentials trusted by the cluster and deliver it to jenkins or k8s worker. No need to encrypt or store the private SSH key anywhere.

It of course requires secret delivery mechanism, as with AWS this could be SSM or in case of K8s this could be built-in secrets or Vault.

[klizhentas]

@kontsevoy we should fix the OSS docs see above.

[kontsevoy]

meeting notes:

Looks like the 24hr cut-off restraint is happening elsewhere (not the default role). This needs to be investigated, the original OSS version was capable of arbitrary TTLs via tctl sign.

[stanchan]

@klizhentas Thanks for the tip... I will look into implementing a client to perform certificate rotations.

[kontsevoy]

@stanchan [while we're looking into this 24hr limit] any interest in taking a look at the enterprise version? it's much more flexible when it comes to RBAC/auth options and possibilities.

[aberoham]

Doesn't look like this is a new regression -- I was able to reproduce what @stanchan is seeing with the latest releases of Teleport OSS (2.0.6, 2.2.8, 2.3.7 and 2.4.6).

tctl sign with a long TTL does work with v1.3.2 (Jan '17)

[kontsevoy]

Comments from a meeting with @klizhentas:

Decisions

• tctl auth sign must always allow unlimited --ttl in both OSS and EE versions (i.e. with RBAC or not).
• documentation already says so. Thus, no changes need to be made in the docs.

Notes

Right now we're slotting this for 2.6.1 as it looks it's a minor fix, may be as easy as changing a constant (?). Feel free to bump if fixing this isn't trivial.