Fortinet black logo

Administration Guide

ZTNA SSH access proxy example

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.

Example

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 public 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>
    -----END OPENSSH PRIVATE KEY-----"
            set public-key "ssh-rsa AAAAB3**********JLXlxj3” 
            set source built-in
        next
    end
    
  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

      Where:

      • 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.

Note

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 192.168.2.87:443:

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

    config firewall address
        edit "SSH_server"
            set subnet 192.168.20.1 255.255.255.255
        next
    end
    
  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="
        next
    end
    
  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"
        next
    end
    
  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"
                        next
                    end
                next
            end
        next
    end
    
  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 "192.168.20.6"
            set secret ENC <secret>
        next
    end
    config user local
        edit "radCurtis"
            set type radius
            set radius-server "Win2k16-Radius"
        next
    end
    config user group
            edit "radius_group"
            set member "radCurtis" "Win2k16-Radius"
        next
    end
    
  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"
        next
    end
    config authentication rule
        edit "ztna-basic"
            set srcaddr "all"
            set ip-based disable
            set active-auth-method "basic_auth"
            set web-auth-cookie enable
        next
    end
    
  8. Configure the full ZTNA policy 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 "radius_group"
            set utm-status enable
            set ssl-ssh-profile "custom-deep-inspection"
        next
    end 
    
To check the results:
  1. On the remote client, open FortiClient, go to the Zero Trust Telemetry tab, and make sure that it is connected to the EMS server.

  2. Go to the ZTNA Destination tab and click Add Destination.

  3. Configure the Destination, then click Create:

    Rule Name

    SSH-Linux

    Destination Host

    192.168.20.1:22

    Proxy Gateway

    192.168.2.87:443

    Mode

    Transparent

    Encryption

    Disabled (recommended)

    When Encryption is disabled, the connection between the client and FortiGate application gateway is not encapsulated in HTTPS after the client and FortiGate connection is established. This allows for less overhead, because SSH is already a secure connection.

  4. Open an SSH client, such as PuTTy, and make an SSH connection to radCurtis@192.168.20.1 on port 22.

  5. After device authentication is performed and passes in the background, FortiClient prompts the user to sign in. Enter the username, radCurtis, and password, then click Sign in.

    After successful user authentication, the SSH connection is established without an additional log in.

  6. On the FortiGate, check the logged in user:

    1. Go to Dashboard > Assets & Identities and expand the Firewall Users widget.

    2. Check the WAD proxy user list:

      # diagnose wad user list
      ID: 2, VDOM: root, IPv4: 10.10.10.25
        user name   : radCurtis
        worker      : 0
        duration    : 614
        auth_type   : Session
        auth_method : Basic
        pol_id      : 5
        g_id        : 12
        user_based  : 0
        expire      : 53
        LAN:
          bytes_in=3403 bytes_out=5699
        WAN:
          bytes_in=3681 bytes_out=3132
  7. The successful connection is logged in the forward traffic logs after the SSH connection has disconnected:

    # execute log display
    25 logs found.
    10 logs returned.
    
    1: date=2021-08-11 time=17:59:56 eventtime=1628729996110159120 tz="-0700" logid="0000000024" type="traffic" subtype="forward" level="notice" vd="root" srcip=10.10.10.25 srcport=50627 srcintf="port1" srcintfrole="wan" dstcountry="Reserved" srccountry="Reserved" dstip=192.168.20.1 dstport=22 dstintf="root" dstintfrole="undefined" sessionid=1926338 srcuuid="5445be2e-5d7b-51ea-e2c3-ae6b7855c52f" service="SSH" proto=6 action="accept" policyid=5 policytype="proxy-policy" poluuid="16fb5550-e976-51eb-e76c-d45e96dfa5dc" policyname="SSH-proxy" duration=67 user="radCurtis" group="radius_group" authserver="Win2k16-Radius" wanin=3681 rcvdbyte=3681 wanout=3132 lanin=3403 sentbyte=3403 lanout=5699 appcat="unscanned"

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.

Example

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 public 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>
    -----END OPENSSH PRIVATE KEY-----"
            set public-key "ssh-rsa AAAAB3**********JLXlxj3” 
            set source built-in
        next
    end
    
  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

      Where:

      • 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.

Note

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 192.168.2.87:443:

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

    config firewall address
        edit "SSH_server"
            set subnet 192.168.20.1 255.255.255.255
        next
    end
    
  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="
        next
    end
    
  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"
        next
    end
    
  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"
                        next
                    end
                next
            end
        next
    end
    
  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 "192.168.20.6"
            set secret ENC <secret>
        next
    end
    config user local
        edit "radCurtis"
            set type radius
            set radius-server "Win2k16-Radius"
        next
    end
    config user group
            edit "radius_group"
            set member "radCurtis" "Win2k16-Radius"
        next
    end
    
  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"
        next
    end
    config authentication rule
        edit "ztna-basic"
            set srcaddr "all"
            set ip-based disable
            set active-auth-method "basic_auth"
            set web-auth-cookie enable
        next
    end
    
  8. Configure the full ZTNA policy 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 "radius_group"
            set utm-status enable
            set ssl-ssh-profile "custom-deep-inspection"
        next
    end 
    
To check the results:
  1. On the remote client, open FortiClient, go to the Zero Trust Telemetry tab, and make sure that it is connected to the EMS server.

  2. Go to the ZTNA Destination tab and click Add Destination.

  3. Configure the Destination, then click Create:

    Rule Name

    SSH-Linux

    Destination Host

    192.168.20.1:22

    Proxy Gateway

    192.168.2.87:443

    Mode

    Transparent

    Encryption

    Disabled (recommended)

    When Encryption is disabled, the connection between the client and FortiGate application gateway is not encapsulated in HTTPS after the client and FortiGate connection is established. This allows for less overhead, because SSH is already a secure connection.

  4. Open an SSH client, such as PuTTy, and make an SSH connection to radCurtis@192.168.20.1 on port 22.

  5. After device authentication is performed and passes in the background, FortiClient prompts the user to sign in. Enter the username, radCurtis, and password, then click Sign in.

    After successful user authentication, the SSH connection is established without an additional log in.

  6. On the FortiGate, check the logged in user:

    1. Go to Dashboard > Assets & Identities and expand the Firewall Users widget.

    2. Check the WAD proxy user list:

      # diagnose wad user list
      ID: 2, VDOM: root, IPv4: 10.10.10.25
        user name   : radCurtis
        worker      : 0
        duration    : 614
        auth_type   : Session
        auth_method : Basic
        pol_id      : 5
        g_id        : 12
        user_based  : 0
        expire      : 53
        LAN:
          bytes_in=3403 bytes_out=5699
        WAN:
          bytes_in=3681 bytes_out=3132
  7. The successful connection is logged in the forward traffic logs after the SSH connection has disconnected:

    # execute log display
    25 logs found.
    10 logs returned.
    
    1: date=2021-08-11 time=17:59:56 eventtime=1628729996110159120 tz="-0700" logid="0000000024" type="traffic" subtype="forward" level="notice" vd="root" srcip=10.10.10.25 srcport=50627 srcintf="port1" srcintfrole="wan" dstcountry="Reserved" srccountry="Reserved" dstip=192.168.20.1 dstport=22 dstintf="root" dstintfrole="undefined" sessionid=1926338 srcuuid="5445be2e-5d7b-51ea-e2c3-ae6b7855c52f" service="SSH" proto=6 action="accept" policyid=5 policytype="proxy-policy" poluuid="16fb5550-e976-51eb-e76c-d45e96dfa5dc" policyname="SSH-proxy" duration=67 user="radCurtis" group="radius_group" authserver="Win2k16-Radius" wanin=3681 rcvdbyte=3681 wanout=3132 lanin=3403 sentbyte=3403 lanout=5699 appcat="unscanned"