client runs with elevated permissions and the command fails (for
instance, when the auth server state has not yet been generated), it
will leave the file behind possibly making further attempts to properly
generate content in data directory by a lower-privilege process impossible.
`tsh` has always supported reverse tunnels via undocumented "sites"
command.
This commit:
1. Renames "sites" to "clusters" to be consistent with the rest of
Teleport naming conventions
2. Adds --cluster flag to `tsh ssh`
3. Updates the User Manual in the documentation dir
Refs #437
`tctl auth` now treats local CAs differently from "trusted CAs":
- `tctl auth ls` prints two tables: local authorities and trusted
authorities.
- `tctl auth export` only exports local keys
Also, when showing "allowed logins" for each CA, tctl now prints "N/A"
for host CAs and user-friendly "<nobody>" or "<everyone>"
1. tctl auth export now dumps both user&host keys if --type key is missing
2. created fixtures for testing key imports: they're in
fixtures/trusted_clusters
3. configuration parser reads "trusted_clusters" files expecting the
output of tctl auth export
- User tokens (signup tokens) and node nodes (provisioning tokens) are
managed via the same API calls.
- User tokens are converted to machine tokens (with Signup role)
- Static node tokens have "Expiry" date of Unix(0) i.e. Jan 1, 1970
Teleport CA-signed host certificates used to support only one
server role per cert.
This commit adds the ability to store multiple roles in a
certificate, paving the road for multi-role node support in
a near future.
This commit:
- Makes all Teleport tokens multi-role (a token is associated with a
list of roles its owner can assume)
- Removes some unused/obsolete features
a) "AllowedTokens" config setting which we don't use
b) "authorities" TCTL command
It does not affect how Teleport works, just preparing the plumbing for
--roles flag for `tctl nodes add`
When a user tries to login with a non-existing mapping (local OS does
not know anything about 'vince') he gets an ugly message:
"ERROR: cannot start shell"
Instead I wanted to show a nicer "host 'turing' does not have a local
user 'vince'"
The closest I could get was a generic 'access denied' + an informative
logging message in teleport logs.
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
- replay now works in both web and CLI
- fixed two nasty connection bugs in web sessions
- removed verbose logging/diagnostics
- refactoring of web code by Alexey
- added getProxyLogin() method to TeleportClient. It now uses the
default approved principal to login into proxy or defaults to "host
login"
- covered a bit more of TeleportClient functionality with basic unit
tests
...by teleport clients + servers, meaning:
1. Servers do not default to stdout when printing startup messages
2. Clients can use arbitrary input/output instead of stdin/stdout when
doing SSH/join. This helps with integration testing.
- Fixed all tests
- Removed "magic constants" in random places
- Improved 'retry connecting to auth server' logic (it used to always
fail on 1st attempt)
