Implement ProxyJump compatibility

[kontsevoy]

Introduction

OpenSSH 7.3 introduced a very convenient way to deal with bastion hosts by adding an option called ProxyJump. See some examples here.

Currently a Teleport proxy cannot be used with ProxyJump. Adding support for this would make OpenSSH clients much easier to use.

Proposal

Adding something to like this to ~/.ssh/config should work:

Host telenode
    port 3022

    # new syntax:
    ProxyJump proxy.example.com.com:3023
    
    # old syntax:
    # ProxyCommand ssh -p 3023 %r@proxy.example.com -s proxy:%h:%p

Passing -J to OpenSSH client (ssh) should work:

$ ssh -J proxy.example.com:3023 telenode

New Flag

If you think about it, -J CLI flag for OpenSSH client is exactly what tsh --proxy is. Therefore let's add -J support to tsh as well, because it's an equivalent of --proxy, in other words this should work too:

$ tsh ssh -J proxy.example.com telenode

... and tsh --help should say, among other things:

$ tsh ssh --help
Flags:
  -J, --proxy               SSH proxy address

Backward Comp

Obviously the legacy ProxyCommand support should continue to work.

Better error handling on Proxy side

Currently if you attempt to use ProxyJump with Teleport 3.1-alpha you get:

$ ssh -J proxy.example.com:3023 telenode
channel 0: open failed: unknown channel type: unknown channel type: direct-tcpip
stdio forwarding failed
ssh_exchange_identification: Connection closed by remote host

BTW fixing that error message (it's duplicated) would also be nice, ideally an error like this should say that it's coming from a proxy, not the node (or auth) so it would be easier to debug/troubleshoot:

$ some-kind-of-command-that-causes-proxy-error
Teleport proxy: unknown channel type 'direct-tcpip'
ssh_exchange_identification: Connection closed by remote host

[kontsevoy]

@klizhentas please review.

[klizhentas]

For some reason I though that ProxyJump already works with Teleport, we should definitely support it. @russjones correctly noted though that proxy jump does not allow us to provide trusted cluster name as a parameter though, so it will work as a limited subset of what we have.

It also does not seem to be very high priority, so I propose to push this to later releases.

[kontsevoy]

ProxyJump allows to take a list of arguments, i.e. a list of jump hosts, which we can use to select the trusted cluster. Since we're adding cluster metadata as well (for other purposes) the auth server should know the proxy URL of the trusted cluster for the next jump, hence this should work:

$ ssh -J proxy.example.com:3023,trusted.example.com:3023

[klizhentas]

good point, I was not aware of that feature, let's schedule for implementation then some time after the "Pleasanton"

[donovan]

Hi.

Issue #2662 seems to be related to this issue. Thought it was worth pointing out that there is a use case that seems to rely on this functionality. Seems I can't provision EC2 instances using the terraform file or remote-exec provisioners when using a teleport proxy. This works fine when using a bastion running OpenSSH Server.