This article discusses connectivity issues related to Okta Privileged Access (OPA) and viewing servers in the user interface.

• Okta Privileged Access (OPA)
• Amazon Web Services (AWS)
• Okta Classic Engine
• Okta Identity Engine (OIE)

• The server has been enrolled, but cannot be seen in the project:
  • Solution: Ensure the security policy state is set to Active and not in Draft state. It might be necessary to publish it if it is in a Draft status (Security Administration > Policies).
• The user is unable to log in when trying through the vaulted password method (with a local managed account). The following error message is seen:

dial: SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain

• • Solution: Make sure passwordAuthentication is set to yes in /etc/ssh/sshd_config on the server. The steps will be: 

    sudo vi /etc/ssh/sshd_config

1. 1. 1. Uncomment the line passwordAuthentication and set it to yes.

• • • • Validate if the passwordAuthentication is set to yes for sshd by using the following command: 

        sshd -T | grep -i passwordauthentication

      • If the output above still shows a "no", then there could be additional configs overwriting the ones in sshd_config. Some cloud providers disable this in a different file. If the reference to this file is before the setting set in the /etc/ssh/sshd_config, then it will take precedence over the second setting. Above could be done, but it will not take effect. The command below will show the file(s) location being referenced:

        sudo grep -i include /etc/ssh/sshd_config

      • If an output is shown, check the contents of the file (an example of this is shown below):

• • • • Set PasswordAuthentication yes

        sudo vi /etc/ssh/sshd_config.d/60-cloudimg-settings.conf

• • 2. Validate the sshd_config (if not done, and the service cannot start, the loss of ssh access could happen due to an improper configuration file).

       sudo sshd -t

       NOTE: If there is an error, do not proceed until everything is clear when running the command above (nothing should be shown).

    3. Restart the sshd and sftd services: 

       sudo systemctl restart sshd

       sudo systemctl restart sftd

NOTE: The service name may vary depending on the platform (for example, the name was found to be "ssh" in Ubuntu 24). In that case, change the systemctl command to use ssh instead of sshd. 

• SSH connection fails when using a sudo-level account access method:
  • Solution:  Ensure all components (for example, client, gateway, and server agent) are version 1.87.1 or later.