To prevent users from being able to directly connect to registered
OpenSSH (Agentless) nodes, the OpenSSH CA was introduced. When
connecting to Agentless nodes, the Proxy will forward the connection
so the session can be recorded. The forwarding SSH server is configured
to authenticate to the target node with a certificate signed by OpenSSH
CA, which users do not have access to.
Prior to the NodeWatcher being successfully initialized, or when
it became stale any calls to `GetNodes` would return no data or
stale data. This behavior results in the problems described in
#22672.
The NodeWatcher will now fallback to pulling data from the cache
in the event that it has no data or stale data when callers attempt
to retrieve nodes. This should reduce the time that it takes the
a new Proxy or a Proxy with intermittent connectivity issues to
Auth be able to route to nodes.
The impact of this change should be noticeable in tests that
create a Proxy and several Nodes and then immediately try to
open a session on the Nodes.
Closes#22672
The RBAC logic assumes that SSH connections to registered OpenSSH nodes
will always be proxied and terminated, which will come in a future PR.
Part of implementing #19261.
Migrates metrics counting proxied connections and connection attempts
from `regular/proxy.go` to `proxy.Router` so that connections via
the web UI, tsh ssh via the Proxy ssh and grpc servers are all
accounted for.
* create package to contain proxy peering code
* Refactor proxy routing logic into a reusable object
Routing logic existed within an unexported handler of ssh subsystem
requests, which prevented it from being reused by other components
within the proxy, like the webapi server. This causes significant
latency issues for web sessions because the web apiserver is required
to dial the proxy ssh server to determine how to route to the host.
Since the web apiserver and the proxy ssh server exist in the same
process this is an entirely unnecesarry step that could be avoided
if the routing and ability to established connections were shared
throughout the proxy.
A new `proxy.Router` object is introduced which contains all the
logic that used to exist in `regular.proxySubsys` for determining
how to connect to servers and clusters. All routing within the
`regular.proxySubsys` now leverages the `proxy.Router` to dial
the target.
This is step 1 in addressing #15167. Now that the `proxy.Router`
exists `web.APIServer` will be able to make use of it to avoid
dialing the same process to establish connections.
Andrew LeFevre