anchor.diff:  <i>This page assumes you are using cf CLI v6.13.0 or later.</i>
   
   The cf CLI lets you securely log into remote host VMs running <%=vars.product_full%> application instances. This topic describes the commands that enable SSH access to applications, and enable, disable, and check permissions for such access.
  +
  +Under the hood, the cf CLI looks up the `app_ssh_oauth_client` identifier in the Cloud Controller `/v2/info` endpoint, and uses this identifier it to query the UAA server for an SSH authorization code. On the target VM side, the SSH proxy contacts the Cloud Controller via the `app_ssh_endpoint` listed in `/v2/info` to confirm permission for SSH access.
   
   ## <a id="ssh-commands"></a>Application SSH Commands
   
  
positive.code: $ cf ssh-code
  E1x89n
  </pre>
  <p class='note'><strong>Note:</strong>The SSH proxy on the target VM contacts the Cloud Controller via the `app_ssh_endpoint` to confirm permission to allow SSH access. The client ID used by the proxy
  must be advertised in the `/v2/info` endpoint under `app_ssh_oauth_client`.  See the [UAA documentation](https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#api-authorization-requests-code-get-oauth-authorize-non-standard-oauth-authorize) for how to allocate an authorization code.</p>
  
  1. Run your `ssh` or other command to connect to the application instance. For the username, use a string of the form cf:APP-GUID/APP-INSTANCE-INDEX@SSH-ENDPOINT, where APP-GUID and SSH-ENDPOINT come from the previous steps. For the port number, pass in the SSH-PORT  also recorded above. APP-INSTANCE-INDEX is the index of the instance you want to access.
  <br/><br/>With the above example, you `ssh` into the container hosting the first instance of your app by running:
  
negative.code: ## <a id="proxy-to-container-auth"></a>Proxy to Container Authentication
  
  A second layer of SSH security runs within each container. When the SSH proxy attempts to handshake with the SSH daemon inside the target
  container, it uses the following fields associated with the `diego-ssh` key in its route to the application instance. This inner layer works invisibly and requires no user action, but is described here to complete the SSH security picture.
  
  ### CONTAINER_PORT (required)
  `container_port` indicates which port inside the container the SSH daemon is
  listening on. The proxy attempts to connect to host side mapping of this
  port after authenticating the client.
  
  ### HOST_FINGERPRINT (optional)
  When present, `host_fingerprint` declares the expected fingerprint of the SSH
  daemon's host public key. When the fingerprint of the actual target's host key
  does not match the expected fingerprint, the connection is terminated. The
  fingerprint should only contain the hex string generated by `ssh-keygen -l`.
  
  ### USER (optional)
  `user` declares the user ID to use during authentication with the container's
  SSH daemon. While this is not a required part of the routing data, it is required
  for password authentication and may be required for public key authentication.
  
  ### PASSWORD (optional)
  `password` declares the password to use during password authentication with
  the container's ssh daemon.
  
  ### PRIVATE_KEY (optional)
  `private_key` declares the private key to use when authenticating with the
  container's SSH daemon. If present, the key must be a PEM encoded RSA or DSA
  public key.
  