"the requested application authentication failed, due to Public Key Authentication method failure on target resource." error using ZTNA SSH application
search cancel

"the requested application authentication failed, due to Public Key Authentication method failure on target resource." error using ZTNA SSH application

book

Article ID: 281687

calendar_today

Updated On:

Products

Symantec ZTNA

Issue/Introduction

ZTNA Admin created an SSH application for access to an internal bastion host.

As part of the application configuration, the public key was installed on the remote host using the curl command, and the sshd_config file pointed to this public key.

ZTNA user can access the Portal, copy the SSH command and token without issues, but  are unable to successfully SSH into the host.

After submitting the token, the following SSH error is reported: 

Received disconnect from #.#.#.#. port 22:14: The good news, you are authorized to access the application.
However, the requested application authentication failed, due to Public Key Authentication method failure on target resource.

This happens with short and long term tokens, and for all users.

SSH access from same user to other ZTNA SSH applications work fine.

Environment

ZTNA.

SSH Application.

Cause

Clock drift of 5 minutes on the SSH server caused x509 cert validation to fails.

Resolution

Point linux host to public NTP server, or make sure that time on host is in sync.

Additional Information

Despite the setup looking good, it was decided to enable the DEBUG3 LogLevel on the Linux SSH server users could not login to successfully.

Looking at the user request when failing, the following key entries showed up.

Mar 15 16:56:09 apache-ab sshd[26911]: error: Certificate invalid: not yet valid
Mar 15 16:56:09 apache-ab sshd[26911]: debug3: mm_answer_keyallowed: publickey authentication test: ED25519-CERT key is not allowed
Mar 15 16:56:09 apache-ab sshd[26911]: Failed publickey for perf from #.#.#.# port xxxx ssh2: ED25519-CERT SHA256:83JKyzjmFwdD5xdIRsUuwcd9JB0sp2C9/G0Ic5grW/I ID USERNAME: [email protected] IP: /115.

Using the 'date' command to validate the timestamp on the host, we could see that it was 5 minutes off the correct time. Manually setting the time quickly via 'date' command allowed the login to succeed.

The SSH server was in a closed network with restricted access to other services, including NTP. Admin opened firewall rule to connect to a trusted time source.