RedisInsight connects clustered databases through SSH

A tunnel to one Redis endpoint does not automatically provide a route to every endpoint in a Redis cluster. Cluster-aware tooling needs to connect using the topology it discovers, which may contain addresses unavailable from the operator's machine. RedisInsight 2.44, released on February 29, adds SSH support for clustered databases by handling those additional connections.

The implementation makes the networking problem concrete. RedisInsight first connects to discover nodes, then constructs tunnels and address mappings for the cluster client. The feature is useful because reaching the initial database address and using the resulting topology are separate requirements. A successful first connection only establishes one of them.

I have used Redis since its release, and I value tooling that preserves the existing data model while making its operational details accessible. An administration client is more useful when it can reach the same private topology that applications already use. Requiring a separate public endpoint arrangement merely to inspect that topology would add another deployment concern.

Discovery precedes the cluster connection

The version-pinned connection strategy begins cluster creation with an ordinary standalone connection. It uses that connection to discover cluster nodes and then disconnects it. This initial client has a specific job. It supplies the topology that the subsequent cluster client needs.

When SSH is enabled, the strategy creates a tunnel for each discovered node using the database's SSH options. It then replaces the root-node list with the local server addresses returned by those tunnels. That gives the cluster client reachable starting points while preserving the distinction between a remote node and the local endpoint used to reach it.

The strategy also builds a NAT map. Each entry uses the remote target host and port as its key and the local tunnel's host and port as its value. The cluster client receives this map with its connection configuration. When topology information refers to the remote address, the mapping supplies the corresponding address available locally.

This extra mapping is the substantial part of cluster tunneling. A plain local forward can carry a TCP connection, but it does not rewrite topology information returned inside the database protocol. The client needs a way to reconcile those advertised endpoints with its usable routes. RedisInsight's strategy supplies that relationship explicitly.

Node identity survives address translation

The cluster client wrapper also accounts for translated addresses when listing nodes. It examines the cluster client's NAT map and attaches the corresponding original host and port as additional node options. This keeps remote identity available alongside the connection address.

That distinction matters for monitoring. A node reached through a loopback address is still a particular remote database node. If every part of the tool treated the local tunnel endpoint as the node's only identity, information obtained from cluster discovery would not line up with information attached to the connection.

The associated cluster monitoring strategy matches a node through either its connection host and port or its retained NAT host and port. The topology and monitoring code therefore share the same distinction. Networking translation changes how the tool reaches the node without changing which remote node its metrics describe.

This is useful beyond the initial connection form. Cluster administration involves relating server-reported identities to the connections used for inspection. Preserving both forms avoids making a local forwarding choice part of the remote database's identity. The code treats address translation as connection metadata that other parts of the tool can interpret.

The monitoring strategy uses each matched client to request INFO data. It derives node details including memory use and replication offsets from that response. Correctly matching translated connections therefore affects the data attached to a node, not merely the address displayed beside its name.

Tunnel lifetime follows the client

The connection strategy retains the created tunnels while constructing the cluster client. When that client ends, its handler closes the tunnels. The error path during setup also attempts to close tunnels already created and disconnect the discovery client. Creating several local forwards therefore comes with explicit cleanup in the surrounding connection lifecycle.

The implementation pull request shows the earlier cluster-SSH rejection being removed as the new path is added. The change replaces an unsupported configuration with discovery and per-node connection setup. It also adjusts supporting node metadata and connection cleanup, which explains why the feature spans more than the user interface's SSH controls.

The available SSH authentication choices include a password or a private key in PEM format. Those authenticate access through SSH. Database authentication remains part of the Redis connection configuration in the strategy. A usable tunnel does not itself supply permission to execute database commands, because transport access and database access are configured separately.

Migration includes the operator's access method

The release identifies this feature as removing an obstacle for some RESP.app users considering RedisInsight. That is a specific tooling migration concern. Existing database clients can already depend on an access method, and replacing the client needs to preserve that method as well as provide a familiar key browser.

The release also changes browser layout and other interface details, but cluster access is the prerequisite for those tools to be useful against a private clustered database. A key browser cannot inspect a node it cannot reach. The connection strategy's topology discovery and endpoint mapping address that prerequisite directly.

My preference is to preserve private database addressing and make the administration client understand the route it has been given. In this implementation, RedisInsight discovers remote nodes, creates the required forwards, and retains the mapping used to reach them. The monitoring layer can still identify the remote nodes after translation, which is necessary for the cluster view to describe the database behind the tunnels.