ZTNA SSH access proxy example

ZTNA can be configured with SSH access proxy to provide a seamless SSH connection to the server.

Advantages of using an SSH access proxy instead of a TCP forwarding access proxy include:

  • Establishing device trust context with user identity and device identity checks.

  • Applying SSH deep inspection to the traffic through the SSH related profile.

  • Performing optional SSH host-key validation of the server.

  • Using one-time user authentication to authenticate the ZTNA SSH access proxy connection and the SSH server connection.

Perform SSH host-key validation of the server

To act as a reverse proxy for the SSH server, the FortiGate must perform SSH host-key validation to verify the identity of the SSH server. The FortiGate does this by storing the public key of the SSH server in its SSH host-key configurations. When a connection is made to the SSH server, if the public key matches one that is used by the server, then the connection is established. If there is no match, then the connection fails.

One-time user authentication

SSH access proxy allows user authentication to occur between the client and the access proxy, while using the same user credentials to authenticate with the SSH server. The following illustrates how this works:

  1. The remote endpoint registers to FortiClient EMS and receives the client certificate.

  2. The remote endpoint tries to connect to the SSH access proxy. It must use the same username that is later used for access proxy authentication.

  3. The FortiGate challenges the endpoint with device identity validation.

  4. The remote endpoint provides the EMS issued certificate for device identification.

  5. The FortiGate challenges the endpoint with user authentication. For example, this could be done with basic or SAML authentication.

  6. The users enters their credentials on the remote endpoint.

  7. The FortiGate authenticates the user and collects the username.

  8. Using the FortiGate's CA or the customer's CA certificate, the FortiGate signs an SSH certificate and embeds the username in its principal.

  9. The FortiGate attempts to connect to the SSH server using the certificate authentication.

  10. The SSH server verifies the authenticity of the certificate, and matches the username principal against its authorized_keys file.

  11. If the username matches a record in the file, then the SSH connection is established. If no match is found, then the SSH connection fails.


In this example, an SSH connection is established using SSH access proxy with host-key validation and one-time authentication.

  • The SSH server is a Linux based server that uses sshd to provide remote access

  • For SSH host-key validation, the public key of the SSH server has been imported into the FortiGate.

  • For one-time authentication using certificate authentication:

    • The SSH server must allow certificate authentication.

    • The SSH server must have the proper entry in its authorized_keys file that contains the user principal and the FortiGate CA's public key.

    • The entry is present in the user directory corresponding to the user that is trying to log in.

To pre-configure the Linux SSH server:
  1. Retrieve the public key used for host-key validation:

    1. Locate the public key files in the SSH server:

      $ ls -la /etc/ssh/*.pub
      -rw-r--r-- 1 root root 186 Mar 29  2020 /etc/ssh/ssh_host_ecdsa_key.pub
      -rw-r--r-- 1 root root 106 Mar 29  2020 /etc/ssh/ssh_host_ed25519_key.pub
      -rw-r--r-- 1 root root 406 Mar 29  2020 /etc/ssh/ssh_host_rsa_key.pub2
    2. Choose the publish key file based on the hash type (in this case, ECDSA), and show it's content:

      $ cat /etc/ssh/ssh_host_ecdsa_key.pub
      ecdsa-sha2-nistp256 AAAAE2*********IpEik=

      This key will be used when configuring the FortiGate.

  2. Retrieve the FortiGate CA’s public key from the FortiGate:

    # show full firewall ssh local-ca Fortinet_SSH_CA
    config firewall ssh local-ca
        edit "Fortinet_SSH_CA"
            set password ENC <hidden password>
            set private-key "-----BEGIN OPENSSH PRIVATE KEY-----
    <hidden private key>
            set public-key "ssh-rsa AAAAB3**********JLXlxj3” 
            set source built-in
  3. On the Linux server, enable the SSH service to use the authorized_keys file:

    1. Locate and edit the /etc/ssh/sshd_config file.

    2. Ensure that the AuthorizedKeysFile line is uncommented, for example:

      AuthorizedKeysFile      .ssh/authorized_keys .ssh/authorized_keys2
  4. Allow remote SSH log in with certificate authentication and principal name:

    1. Log in to the SSH server using the account that will be granted remote SSH access (in this example: radCurtis):

    2. Locate the account's authorized_keys file in the ~/.ssh directory:

      $ ls -la ~/.ssh
      total 12
      drwxrwxr-x 2 radCurtis radCurtis 4096 Aug 10 19:14 .
      drwxr-xr-x 5 radCurtis radCurtis 4096 Aug 10 19:13 ..
      -rw-rw-r-- 1 radCurtis radCurtis  419 Aug 10 19:14 authorized_keys
    3. If the directory and file do not exist, create the directory:

      $ mkdir ~/.ssh
    4. Create an entry containing the following keywords and add them to the authorized_keys file:

      echo 'cert-authority,principals="radCurtis" ssh-rsa AAAAB3**********JLXlxj3' >> authorized_keys


      • cert-authority - indicates that this entry is used in certificate authentication by validating the certificate using the public key provided in this entry.

      • principals="radCurtis" - indicates the user that must match with the username embedded in the SSH certificate.

      • ssh-rsa AAAAB3**********JLXlxj3 - indicates the FortiGate CA’s public key that is used to validate the SSH certificate.

  5. Restart the sshd service:

    $ sudo systemctl stop sshd
    $ sudo systemctl start sshd

    The SSH server can now accept SSH connection from radCurtis@<server IP>, where the SSH certificate used by the FortiGate to log in contains radCurtis embedded as a principal.


When a user connects from a SSH client using <username>@<server IP>, sshd will locate the authorized_keys file in the directory /home/<username>/.ssh/authorized_keys. If the authorized_keys is not in that directory, authentication will fail on the SSH server side.

If you suspect that authentication is failing on the SSH server, use the following commands to manually start sshd in debug mode to troubleshoot:

$ sudo systemctl stop sshd
$ /usr/sbin/sshd -ddd -p 22
To configure the FortiGate :
  1. Configure a new VIP to allow access to the SSH access proxy over

    config firewall vip
        edit "ZTNA_SSH"
            set type access-proxy
            set extip
            set extintf "any"
            set server-type https
            set extport 443
            set ssl-certificate "Fortinet_CA_SSL"
  2. Configure the address object for the SSH server:

    config firewall address
        edit "SSH_server"
            set subnet
  3. Configure the host-key that will be used to authenticate the SSH server. The public-key was retrieved when pre-configure the Linux SSH server (step 1b).

    config firewall ssh host-key
        edit "ed25519"
            set type ECDSA
            set usage access-proxy
            set public-key "AAAAE2**********IpEik="
  4. Configure the access proxy SSH client certificate:

    A CA certificate is assigned to sign the SSH certificate that will be used in the SSH authentication. The SSH certificate will have the username embedded in the certificate principal.

    config firewall access-proxy-ssh-client-cert
        edit "ssh-access-proxy"
            set source-address enable
            set auth-ca "Fortinet_SSH_CA"
  5. Configure the access-proxy server setting:

    config firewall access-proxy
        edit "ZTNA_SSH"
            set vip "ZTNA_SSH"
            set client-cert enable
            config api-gateway
                edit 1
                    set url-map "tcp"
                    set service tcp-forwarding
                    config realservers
                        edit 1
                            set address "SSH_server"
                            set type ssh
                            set ssh-client-cert "ssh-access-proxy"
                            set ssh-host-key-validation enable
                            set ssh-host-key "ed25519"
  6. Configure the RADIUS setting, user setting, and user group to apply user authentication to the access proxy connection using RADIUS:

    config user radius
        edit "Win2k16-Radius"
            set server ""
            set secret ENC <secret>
    config user local
        edit "radCurtis"
            set type radius
            set radius-server "Win2k16-Radius"
    config user group
            edit "radius_group"
            set member "radCurtis" "Win2k16-Radius"
  7. Create the authentication scheme and rule to perform the authentication:

    config authentication scheme
        edit "basic_auth"
            set method basic
            set user-database "Win2k16-Radius"
    config authentication rule
        edit "ztna-basic"
            set srcaddr "all"
            set ip-based disable
            set active-auth-method "basic_auth"
            set web-auth-cookie enable
  8. Configure the ZTNA rule to allow traffic to the SSH server, and apply user authentication, posture check, and a security profile where necessary:

    config firewall proxy-policy
        edit 5
            set name "SSH-proxy"
            set proxy access-proxy
            set access-proxy "ZTNA_SSH"
            set srcintf "port1"
            set srcaddr "all"
            set dstaddr "all"
            set ztna-ems-tag "FCTEMS8821001056_ems138_av_tag"
            set action accept
            set schedule "always"
            set groups "radi