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.
* 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.
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.
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
```
Summary:
Sasha proposed to use the certificate principal instead of the host name
when establishing new SSH connections.
What I did:
Replaced `ReadKeys()` function in `auth/init.go` with `ReadIdentity()`
which, instead of a simple "key signer" returns a more comprehensive
structure called "Identity"
The structure has the `Cert` field which can be used to obtain "valid
principals".
The first principal is used as an SSH username, instead of the hostname
like before.
dmitri