Understanding SSH Access Configuration

Page last updated: December 17, 2015

This document describes configuration for SSH access to Cloud Foundry (CF) application instances. Cloud Foundry supports SSH access for DEA and Diego back ends, and the HAProxy load balancer.

Diego Configuration

You can configure SSH access for Cloud Foundry app instances running on Diego. The SSH proxy instances facilitate access to apps with these BOSH properties:

  • diego.ssh_proxy.host_key: The Diego SSH proxy instances utilize a PEM-encoded RSA private host key. Pivotal recommends deployment operators generate individual keypairs for each deployment and supply those in the manifest.

  • diego.ssh_proxy.enable_cf_auth: This property determines whether to activate the CF Authenticator in the proxies. It must be enabled for the cf ssh plugin to connect to the Diego SSH server running in the instance.

  • diego.ssh_proxy.enable_diego_auth: This property determines whether to activate the Diego Authenticator in the proxies. For a production CF+Diego deployment, this property should be disabled, as it grants access to any instance running the Diego SSH server with only the receptor credentials. Development deployments may choose to enable it to provide an alternate mechanism to establish SSH sessions.

The properties diego.ssh_proxy.cc.internal_service_hostname and diego.ssh_proxy.cc.external_port should not require direct configuration if an operator uses the spiff-based manifest-generation scripts to generate the Diego deployment manifest.

CF Configuration

For Cloud Foundry app instances running on DEAs you can configure SSH access wtih these BOSH properties.

The following BOSH properties are relevant for SSH configuration in cf-release:

  • app_ssh.host_key_fingerprint: Fingerprint of the public key presented by the SSH host. In this case, the SSH host refers to the Diego layer of SSH proxies. The value must be set to the fingerprint of the public key of the keypair generated for the diego.ssh_proxy.host_key value in the Diego deployment manifest.
  • app_ssh.port: This property represents the port of the externally routable SSH endpoint advertised through the Cloud Controller information endpoint.
  • cc.allow_app_ssh_access: As mentioned above, whether to allow SSH access at all for CF app instances.

If SSH access is granted for the CF deployment, Cloud Controller advertises the SSH endpoint as ssh.<SYSTEM-DOMAIN>, and accepts traffic on the port given in app_ssh.port. The Cloud Controller /v2/info endpoint provides this SSH endpoint in the app_ssh_endpoint field and the host key fingerprint mentioned above in the app_ssh_host_key_fingerprint field.

SSH Load Balancer configuration

If the HAproxy job from cf-release is used as the gorouter load balancer and cc.allow_app_ssh_access is set to true, HAproxy will also serve as the load balancer for Diego’s SSH proxies. This configuration relies on the presence of the same consul server cluster that Diego components use for service discovery. This configuration also works well for deployments where all traffic on the system domain and its subdomains is directed towards the HAproxy job, as is the case for a BOSH-Lite CF deployment on the default 10.244.0.34.xip.io domain.

For AWS deployments, where the infrastructure offers load-balancing as a service through ELBs, the deployment operator can provision an ELB to balance load across the Diego SSH proxy instances. This ELB should be configured to listen to TCP traffic on the port given in app_ssh.port and to send it to port 2222. In order to register the SSH proxies with this ELB, the ELB identifier should then be added to the elbs property in the cloud_properties hash of the Diego manifest’s access_zN resource pools. If the spiff-based manifest-generation templates are used to produce the Diego manifest, these cloud_properties hashes should be specified in the iaas_settings.resource_pool_cloud_properties section of the iaas-settings.yml stub.