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.

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"