anchor.diff:  
   ### <a id='diego-configuration'></a> Diego Architecture
   
  -To enable SSH access to apps running on Diego, configure the BOSH and UAA properties in your deployment manifests as follows.
  -
  -#### <a id='bosh-configuration'></a> Diego Properties
  -
  -Configure the following properties in your manifest for Diego, `diego.yml`.
  -
  -1. `diego.ssh_proxy.host_key`: Generate a unique key pair and supply the PEM-encoded RSA private host key for this value. This secures the Application SSH proxy running in the instance container.
  -
  -1. `diego.ssh_proxy.enable_cf_auth`: Set this property to `true` to activate the CF Authenticator in the proxies. This enables the `cf ssh` command to connect with the SSH proxy.
  -
  -1. `diego.ssh_proxy.enable_diego_auth`: Set this property to `false` to disable the Diego Authenticator in the proxies, preventing SSH access through Diego API calls.
  -<p class='note'><strong>Note:</strong> Developers running development deployments can enable this property to support API calls, as an alternate mechanism to establish SSH sessions.</p>
  -
  -1. `diego.ssh_proxy.cc.internal_service_hostname` and `diego.ssh_proxy.cc.external_port`: If you use `generate_deployment_manifest` or another spiff-based manifest-generation script, you do not need to configure these properties.
  -
  -#### <a id='uaa-configuration'></a> UAA Properties
  -
  -Configure properties in your Cloud Foundry manifest, `cf-deployment.yml`, as follows.
  -
  -1. Create a stub YAML file `uaa.yml` based on the template below:
  -<pre><code>
  -properties:
  -  <<: (( merge ))
  +To enable SSH access to apps running on Diego, you must register your `ssh-proxy` client with your User Account and Authentication (UAA) server and configure the properties in your deployment manifests by following the steps below.
  +
  +To configure manifest properties, you can edit them directly or put them in stub files with [merge tags](https://github.com/cloudfoundry-incubator/spiff#-merge-) that you pass to `generate_deployment_manifest` or another spiff-based manifest-generation script.
  +
  +#### <a id='cf-manifest'></a> UAA Client Registration
  +
  +To enable SSH access to apps, you must have `ssh-proxy` registered as a client with your UAA server. For more information about configuring UAA, review the [User Account and Authentication (UAA) Server](../concepts/architecture/uaa.html) topic.
  +
  +1. Install the UAA Command Line Interface (UAAC).
  +<pre class="terminal">$ gem install cf-uaac</pre>
  +
  +1. Target your UAA server.
  +<pre class="terminal">$ uaac target uaa.YOUR-SYSTEM-DOMAIN</pre>
  +
  +1. Authenticate and retrieve your admin client token. When prompted with `Client secret`, enter your admin credentials.
  +<pre class="terminal">$ uaac token client get admin
  +Client secret:  ********************
  +Successfully fetched token via client credentials grant.
  +Target: <span>https</span>://uaa.YOUR-SYSTEM-DOMAIN
  +Context: admin, from client admin</pre>
  +
  +1. Display your client registrations. 
  +<pre class="terminal">$ uaac clients
  +...
  +  ssh-proxy
  +    scope: cloud\_controller.read cloud\_controller.write openid
  +    resource\_ids: none
  +    authorized\_grant_types: authorization\_code
  +    redirect\_uri: /login
  +    autoapprove: true
  +    action: none
  +    authorities: uaa.none
  +    lastmodified: 1455922096000
  +...
  +</pre>
  +
  +1. If `ssh-proxy` does not appear in your client registrations, you must register a `ssh-proxy` client with UAA.
  +<pre class="terminal">$ uaac client add ssh-proxy -i
  +New client secret: ******
  +Verify new client secret: ******
  +scope (list): cloud\_controller.read cloud\_controller.write openid
  +authorized grant types (list): authorization_code
  +authorities (list): uaa.none
  +access token validity (seconds): [Press Enter]
  +refresh token validity (seconds): [Press Enter]
  +redirect\_uri: /login
  +autoapprove: true
  +signup redirect url(url): [Press Enter]
  +</pre>
  +
  +#### <a id='diego-manifest'></a> Diego Manifest
  +
  +Your manifest for Diego, `diego.yml`, should include the following properties:
  +<pre><code>properties:
  +  ssh\_proxy:
  +    host\_key: |
  +      -----BEGIN RSA PRIVATE KEY-----
  +      YOUR\_PRIVATE\_KEY
  +      -----END RSA PRIVATE KEY-----
  +    enable\_cf\_auth: true
  +    enable\_diego\_auth: false
  +    diego\_credentials: "YOUR\_BASIC\_AUTH\_PASSWORD"
  +    uaa\_secret: SSH-PROXY-SECRET
  +    uaa\_token_url: <span>https</span>://uaa.YOUR-SYSTEM-DOMAIN/oauth/token
  +</code></pre>
  +
  +1. `ssh_proxy.host_key`: Supply the PEM-encoded private key from the RSA key pair that you originally generated for your deployment. This key secures the Application SSH proxy running in each container.
  +<p class="note"><strong>Note</strong>: Pivotal recommends that you generate a unique key pair for each deployment.</p>
  +
  +1. Set the way SSH proxies authenticate access, via CF Authentication or Diego Authentication.
  +  - For a production environment, specify CF Authentication only by setting `ssh_proxy.enable_cf_auth` to `true` and `ssh_proxy.enable_diego_auth` to `false`. This restricts SSH access to the `cf ssh` command, which requires a RSA key pair.
  +  - In a development environment you can enable less-secure Diego Authentication by setting `ssh_proxy.enable_diego_auth` to `true` and `ssh_proxy.diego_credentials` to a password. This lets any user with the password establish SSH connections through the Diego API, without running `cf ssh`.
  +
  +1. For `SSH-PROXY-SECRET`, provide the `Client secret` for the `ssh-proxy` client registered with your UAA server.
  +
  +1. To complete the `uaa_token_url` field, provide `YOUR-SYSTEM-DOMAIN`.
  +
  +#### <a id='cf-manifest'></a> Cloud Foundry Manifest
  +
  +Your manifest for Cloud Foundry, `cf-deployment.yml` should include the following properties:
  +
  +<pre><code>properties:
     app_ssh:
       host_key_fingerprint: HOST-KEY-FINGERPRINT
       oauth_client_id: ssh-proxy
  
positive.code: 
  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 `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.
  
negative.code: 
  <strong><%= modified_date %></strong>
  
  This topic describes how to configure your Cloud Foundry deployment to allow SSH access to application instances, and includes details about load balancing SSH sessions.
  
  ## <a id='architecture-configuration'></a> Cloud Foundry Configuration
  
  