Teleport usability issues

[kontsevoy]

These things are UX issues, but they would greatly slow me down if I wasn't familiar with Teleport code.

Handling non-existent user logins

I have two trusted clusters, "master" and "appliance". Using master as my proxy:

$ tsh --proxy=master --cluster=appliance ssh bob@hostname

If bob does not exist on "hostname" this will silently fail. It does not print "Bob does not exist".

Handling Unreachable nodes

Same situation as above, try this:

$ tsh --proxy=master --cluster=appliance ssh badhost

If badhost is not reacheable (for example teleport ports are blocked via iptables) this command will:

• It will not print a proper error message, saying "no route to badhost"
• It will cause "master" teleport daemon to drop the tunnel connection, disconnecting "appliance" (and killing all active sessions to it!)

Access Denied Reporting

Based on either you have a session key or not, the error message is different (and cryptic).
With empty .tsh:

$ tsh --proxy=localhost ssh baduser@localhost
ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

With session keys in .tsh:

$ tsh --proxy=localhost ssh baduser@localhost
access denied to login "bar" when connecting to localhost:3022: failed to connect to "localhost:3022@default@9598f6db-4fc4-4336-82a1-81a827049fa6"

Handling Unreachable Hosts

This is inside a local cluster:

~/go/src/github.com/gravitational/teleport: tsh --proxy=localhost ssh badhost

ERROR REPORT:
Original Error: *trace.ConnectionProblemError dial tcp: lookup badhost: no such host
Stack Trace:
	/Users/ekontsevoy/go/src/github.com/gravitational/teleport/lib/srv/proxy.go:260 github.com/gravitational/teleport/lib/srv.(*proxySubsys).proxyToHost
	/Users/ekontsevoy/go/src/github.com/gravitational/teleport/lib/srv/proxy.go:145 github.com/gravitational/teleport/lib/srv.(*proxySubsys).start
	/Users/ekontsevoy/go/src/github.com/gravitational/teleport/lib/srv/sshserver.go:834 github.com/gravitational/teleport/lib/srv.(*Server).handleSubsystem
	/Users/ekontsevoy/go/src/github.com/gravitational/teleport/lib/srv/sshserver.go:751 github.com/gravitational/teleport/lib/srv.(*Server).dispatch
	/Users/ekontsevoy/go/src/github.com/gravitational/teleport/lib/srv/sshserver.go:717 github.com/gravitational/teleport/lib/srv.(*Server).handleSessionRequests
	/usr/local/go/src/runtime/asm_amd64.s:2087 runtime.goexit
User Message: failed to connect to server <nil>

To fix: remove "stack dump" and use the normal error message.

[klizhentas]

I think problem number 2 happens pretty much because of this line:

https://github.com/gravitational/teleport/blob/master/lib/reversetunnel/remotesite.go#L168

I think it's safe to remove this line, as it the fact that we failed to dial does not mean that connection is broken. We can just rely on the heartbeat logic here:

https://github.com/gravitational/teleport/blob/master/lib/reversetunnel/remotesite.go#L138

that will invalidate this connection after timeout what is way more reliable