1. `tsh kube clusters` - lists registered kubernetes clusters
note: this only includes clusters connected via `kubernetes_service`
2. `tsh kube credentials` - returns TLS credentials for a specific kube
cluster; this is a hidden command used as an exec plugin for kubectl
3. `tsh kube login` - switches the kubectl context to one of the
registered clusters; roughly equivalent to `kubectl config
use-context`
When updating kubeconfigs, tsh now uses the exec plugin mode:
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins
This means that on each kubectl run, kubectl will execute tsh with
special arguments to get the TLS credentials.
Using tsh as exec plugin allows us to put a login prompt when certs
expire. It also lets us lazy-initialize TLS certs for kubernetes
clusters.
Local keystore records trusted TLS CA certs in `<host>/certs.pem`.
When loading client.Key, also load the TLS CA cert for
`key.TrustedCertificates` field.
Without this field, `kubeconfig.Update` called by tsh can't populate the
CA cert in kubeconfig, which causes x509 validation errors with kubectl.
Previous Login code path was calling itself recursively.
In some cases that lead to endless loops with browser
opening up forever.
This commit factors out retry logic to RetryWithLogin
decorator handler that is used by CLI explicitly.
Client code became better as a result as there are no
hidden side effects.
Added utils.CertChecker that wraps a ssh.CertChecker. The new
certificate checker first checks if the certificate is a valid
certificate for Teleport. At the moment that is 2048-bit RSA then calls
the underlying certificate checker to perform the requested validation.
This issue updates #1986.
This is intial, experimental implementation that will
be updated with tests and edge cases prior to production 2.7.0 release.
Teleport proxy adds support for Kubernetes API protocol.
Auth server uses Kubernetes API to receive certificates
issued by Kubernetes CA.
Proxy intercepts and forwards API requests to the Kubernetes
API server and captures live session traffic, making
recordings available in the audit log.
Tsh login now updates kubeconfig configuration to use
Teleport as a proxy server.
This commit introduced mutual TLS authentication
for auth server API server.
Auth server multiplexes HTTP over SSH - existing
protocol and HTTP over TLS - new protocol
on the same listening socket.
Nodes and users authenticate with 2.5.0 Teleport
using TLS mutual TLS except backwards-compatibility
cases.
* Closes#1212 (OpenSSH-compatible naming of user identity files stored
in ~/.tsh/keys
* Closes#1128 (cache location collision when connecting two different
proxies with similar cluster names)
When `tsh login` saves the ephemeral credentials (private key + cert) to
`~/.tsh/keys` it now uses 0600 instead of 0640 for the files and 0700
for `~/.tsh` dir
Fixes#1171
This commit adds several improvements to how CLI SSH login works
- Validated keys are added to the SSH agent [1]
- tsh will does not verify host keys twice anymore
- error messages for "access denied" look clean now
[1] This is huge. This means that tsh login can "feed" the keys to the
built-in SSH agents of the OS and OpenSSH can fetch them from there.
QUESTION: why do we even need `tsh agent` option then? ssh-agent is
installed on every Linux/OSX machine.
This commit closes#529
Teleport was using nanoseconds to set the certificate expiration,
instead of milliseconds.
Changes:
- Switched from nanoseconds to seconds
- Switched from UTC to native time (because that's what golang/x/ssh
uses internally)
* Downgraded many messages from `Debug` to `Info`
* Edited messages so they're not verbose and not too short
* Added "context" to some
* Added logical teleport component as [COMPONENT] at the beginning of
many, making logs **vastly** easier to read.
* Added one more logging level option when creating Teleport (only
Teleconsole uses it for now)
The output with 'info' severity now look extremely clean.
This is startup, for example:
```
INFO[0000] [AUTH] Auth service is starting on turing:32829 file=utils/cli.go:107
INFO[0000] [SSH:auth] listening socket: 127.0.0.1:32829 file=sshutils/server.go:119
INFO[0000] [SSH:auth] is listening on 127.0.0.1:32829 file=sshutils/server.go:144
INFO[0000] [Proxy] Successfully registered with the cluster file=utils/cli.go:107
INFO[0000] [Node] Successfully registered with the cluster file=utils/cli.go:107
INFO[0000] [AUTH] keyAuth: 127.0.0.1:56886->127.0.0.1:32829, user=turing file=auth/tun.go:370
WARN[0000] unable to load the auth server cache: open /tmp/cluster-teleconsole-client781495771/authservers.json: no such file or directory file=auth/tun.go:594
INFO[0000] [SSH:auth] new connection 127.0.0.1:56886 -> 127.0.0.1:32829 vesion: SSH-2.0-Go file=sshutils/server.go:205
INFO[0000] [AUTH] keyAuth: 127.0.0.1:56888->127.0.0.1:32829, user=turing.teleconsole-client file=auth/tun.go:370
INFO[0000] [AUTH] keyAuth: 127.0.0.1:56890->127.0.0.1:32829, user=turing.teleconsole-client file=auth/tun.go:370
INFO[0000] [Node] turing connected to the cluster 'teleconsole-client' file=service/service.go:158
INFO[0000] [AUTH] keyAuth: 127.0.0.1:56892->127.0.0.1:32829, user=turing file=auth/tun.go:370
INFO[0000] [SSH:auth] new connection 127.0.0.1:56890 -> 127.0.0.1:32829 vesion: SSH-2.0-Go file=sshutils/server.go:205
INFO[0000] [SSH:auth] new connection 127.0.0.1:56888 -> 127.0.0.1:32829 vesion: SSH-2.0-Go file=sshutils/server.go:205
INFO[0000] [Node] turing.teleconsole-client connected to the cluster 'teleconsole-client' file=service/service.go:158
INFO[0000] [Node] turing.teleconsole-client connected to the cluster 'teleconsole-client' file=service/service.go:158
INFO[0000] [SSH] received event(SSHIdentity) file=service/service.go:436
INFO[0000] [SSH] received event(ProxyIdentity) file=service/service.go:563
```
You can easily tell that auth, ssh node and proxy have successfully started.
Fixes#392Fixes#396
Teleport now respects `--user` flag and, if --user is specified,
forces the certificate to belong to the given user.
This changes the file structure in `~/.tsh` directory. If a user logs in
under two different accounts, say "ekontsevoy" and "vince", it looks
like this:
```
~/.tsh/
├── keys
│ └── localhost
│ ├── ekontsevoy.cert
│ ├── ekontsevoy.key
│ ├── ekontsevoy.pub
│ ├── vince.cert
│ ├── vince.key
│ └── vince.pub
└── known_hosts
```
Also, to make tests more believable, I have added 3 more pre-generated
keys to 'testauthority' fixture, so instead of returning the same key
over and over, it now returns a random 1 of 4
1. Server now always uses UTC timestamps for certificates it ussues
2. Client doesn't store cert validBefore time in separate files, it
parses the cert itself.
Fixes#370
Started re-writing Teleport client keystore. From a buggy JSON-to-file
to a standard, directory/filebased API behind a standard interface to
allow for alternative implementations.
```
~/.tsh/
└── sessions
└── localhost
├── cert
├── key
└── pub
```
Goal: Easier manipulation of client keys
- configurable key store
- easier public API to sign & save keys (prior to this only tc.Login()
could create a signed key) - this allows to implement custom Login
logic in other clients.
auth server. This is needed when you configure cluster from scratch and
all nodes including auth server spin up simultaneously.
* Add tctl tools to generate keys and certificates
+ Command "tctl authorities gen" generates public and private keypair.
+ Command "tctl authorities gencert" generates public and private keypair signed
by existng private key
+ Command "tctl authorities export" was modified to be able to export exisitng private
CA keys to local storage
All of these commands are hidden by default.
section "static configuration"
* Add ability to configure teleport from environment variable
Environment variable TELEPORT_CONFIG can contain base64 encoded
YAML file config file of the standard file format, so teleport will use it on start
* Add special secrets section to the config file
Section "secrets" was updated to support pre-configured trusted CA keys and pre-generated keys
* Add special rts hidden section to add support for provisioning
