Configuring SSH access for your deployment

Page last updated:

If you need to troubleshoot an instance of an application, you can gain SSH access to the app using the SSH proxy and daemon. For example, one of the app instances might be unresponsive, or the log output from the app is inconsistent or incomplete. You can SSH into the individual VM to troubleshoot the problem instance.

Note: If you have mutual TLS between the Gorouter and app containers, app containers accept incoming communication only from the Gorouter. This disables cf ssh. For more information, see the TLS to Apps and Other Back End Services section of the HTTP Routing topic.

About SSH access

The SSH system components include the SSH proxy and daemon, and the system also supports authentication and load balancing of incoming SSH traffic. For a conceptual overview, see App SSH components and processes.

SSH access control hierarchy

Operators, space managers, and space developers can configure SSH access for Cloud Foundry, for spaces, and for apps as described in the table:

User role Scope of SSH permissions control How they define SSH permissions
Operator Entire deployment Configure the deployment to allow or prohibit SSH access (one-time). For more information, see Configuring SSH Access for Cloud Foundry.
Space manager Space cf CLI allow-space-ssh and disallow-space-ssh commands
Space developer App cf CLI enable-ssh and disable-ssh commands

An app is SSH-accessible only if operators, space managers, and space developers all grant SSH access at their respective levels. For example, the following image shows a deployment in whi:

  • An operator allowed SSH access at the deployment level.
  • A space manager allowed SSH access for apps running in spaces “A” and “B,” but not “C”.
  • A space developer activated SSH access for apps that include “Foo”, “Bar,” and “Baz”.

As a result, apps “Foo”, “Bar,” and “Baz” accept SSH requests.

alt-text="This diagram shows examples of successful and unsuccessful SSH Application Access Control in deployments."

Space A has SSH Access Enabled, indicated by a green check mark, for apps “Foo” and “Bar,” Space A does not have SSH Access allowed for the third app, indicated by a red X.

Space B has has SSH Access Enabled, indicated by a green check mark, for app “Baz”. Space B does not have SSH Access allowed for the other two apps, indicated by a red X.

Space C does not have SSH Access allowed for all three apps, indicated by a red X.

SSH access for apps and spaces

Space managers and space developers can configure SSH access from the CLI. The Cloud Foundry Command Line Interface (cf CLI) also includes commands to return the value of the SSH access setting. To use and configure SSH at both the app level and the space level, see Accessing apps with Diego SSH.

Configuring SSH access for Cloud Foundry

Cloud Foundry deployments control SSH access to apps at the Cloud Foundry level. Additionally, Cloud Foundry supports load balancing of SSH sessions. For more information about setting SSH access for your deployment, see Configuring SSH Access.

View the source for this page in GitHub