Add a dedicated client to communicate with the Proxy SSH servers#22629
Add a dedicated client to communicate with the Proxy SSH servers#22629rosstimothy merged 1 commit intomasterfrom
Conversation
cf77fa6 to
9e091f4
Compare
gzdunek
left a comment
There was a problem hiding this comment.
Approved, but I'm not familiar with this part of the codebase, so you may want to request a review from someone else from group 2.
9e091f4 to
1a47200
Compare
|
Friendly ping @timothyb89 |
|
@timothyb89 PTAL? |
timothyb89
left a comment
There was a problem hiding this comment.
This looks reasonable. I'm excited to see this in tsh ssh!
| if err != nil && !strings.Contains(err.Error(), "agent: already have handler for") { | ||
| return nil, trace.Wrap(err) | ||
| } |
There was a problem hiding this comment.
I assume this error is safe to ignore? Might be worth a quick comment since we usually bubble it up (aside from client.ConnectToNode() at least)
There was a problem hiding this comment.
The agent: already have handler for errors are safe to ignore as they indicate we're already handling the auth-agent@openssh.com channel so the agent forwarding should still function. I'll add a comment with some details.
A new `api/client/proxy/Client` has been added to interact with the SSH and gRPC servers that the Proxy serves on its SSH port. The client will first try connecting to the gRPC server and if that fails it will fall back to the SSH server. Much of the SSH functionality mimics the existing behavior of the `ProxyClient` in `lib/client`. This is the first part of phasing out that client in favor of the new client. There will be a follow up PR that migrates `lib/client` to make use of the new client instead. Part of #19812
d37f2eb to
f97c312
Compare
A new `api/client/proxy/Client` has been added to interact with the SSH and gRPC servers that the Proxy serves on its SSH port. The client will first try connecting to the gRPC server and if that fails it will fall back to the SSH server. Much of the SSH functionality mimics the existing behavior of the `ProxyClient` in `lib/client`. This is the first part of phasing out that client in favor of the new client. There will be a follow up PR that migrates `lib/client` to make use of the new client instead. Part of #19812
A new `api/client/proxy/Client` has been added to interact with the SSH and gRPC servers that the Proxy serves on its SSH port. The client will first try connecting to the gRPC server and if that fails it will fall back to the SSH server. Much of the SSH functionality mimics the existing behavior of the `ProxyClient` in `lib/client`. This is the first part of phasing out that client in favor of the new client. There will be a follow up PR that migrates `lib/client` to make use of the new client instead. Part of #19812
* Add a dedicated client to communicate with the Proxy SSH server (#22629) A new `api/client/proxy/Client` has been added to interact with the SSH and gRPC servers that the Proxy serves on its SSH port. The client will first try connecting to the gRPC server and if that fails it will fall back to the SSH server. Much of the SSH functionality mimics the existing behavior of the `ProxyClient` in `lib/client`. This is the first part of phasing out that client in favor of the new client. There will be a follow up PR that migrates `lib/client` to make use of the new client instead. Part of #19812 * Make `proxy.Client` infer the cluster name from Proxy (#23644) Instead of relying on users to provide the cluster name, the client now determines the cluster name by inspecting the certificate presented by the Proxy during the TLS or SSH handshake. This is required when connecting to a Proxy via a jump host since the name of the cluster may not match the currently logged in cluster. This is achieved by leveraging a custom `credentials.TransportCredentials` when connecting via gRPC and a custom `ssh.HostKeyCallback` when connecting SSH.
* Add a dedicated client to communicate with the Proxy SSH server (#22629) A new `api/client/proxy/Client` has been added to interact with the SSH and gRPC servers that the Proxy serves on its SSH port. The client will first try connecting to the gRPC server and if that fails it will fall back to the SSH server. Much of the SSH functionality mimics the existing behavior of the `ProxyClient` in `lib/client`. This is the first part of phasing out that client in favor of the new client. There will be a follow up PR that migrates `lib/client` to make use of the new client instead. Part of #19812 * Make `proxy.Client` infer the cluster name from Proxy (#23644) Instead of relying on users to provide the cluster name, the client now determines the cluster name by inspecting the certificate presented by the Proxy during the TLS or SSH handshake. This is required when connecting to a Proxy via a jump host since the name of the cluster may not match the currently logged in cluster. This is achieved by leveraging a custom `credentials.TransportCredentials` when connecting via gRPC and a custom `ssh.HostKeyCallback` when connecting SSH.
A new
api/client/proxy/Clienthas been added to interact withthe SSH and gRPC servers that the Proxy serves on its SSH port.
The client will first try connecting to the gRPC server and if
that fails it will fall back to the SSH server - this ensures backwards
compatibility.
Much of the SSH functionality mimics the existing behavior of the
ProxyClientinlib/client. This is the first part of phasingout that client in favor of the new client. There will be a follow
up PR that migrates
lib/clientto make use of the new client introducedhere.
Part of #19812
Note: The first commit moves
api/client/proxy/proxy.gotoapi/utils.proxy.goin order to avoid circular dependencies.