TPAM RHEL 8 Test System issue

IS RHEL 8 is support in TPAM? If yes iam facing this issue 

The results from the test of system HOSTNAME follow (all times are Server Time):

[09/12/2021 09:59:02] PartitionName=,SName=HOSTNAME,PartitionedSName=HOSTNAME

[09/12/2021 09:59:02] Gathering the information necessary to perform a check of HOSTNAME...

[09/12/2021 09:59:02] Checking the Linux System HOSTNAME...

[09/12/2021 09:59:02] RSULT:65280

[09/12/2021 09:59:02] spawn -nottyinit /usr/bin/ssh -2 -v -l functionaccount -i /home/functionaccount/keys/id_dsa -i /home/functionaccount/keys/id_rsa -p 22 -o BatchMode=yes -o PasswordAuthentication=no -o ConnectTimeout=20 X.X.X.X sudo grep -w functionaccount /etc/shadow

[09/12/2021 09:59:02] OpenSSH_7.4p1, OpenSSL 1.0.2j 26 Sep 2016

[09/12/2021 09:59:02] debug1: Reading configuration data /etc/ssh_config

[09/12/2021 09:59:02] debug1: Connecting to X.X.X.X [X.X.X.X] port 22.

[09/12/2021 09:59:02] debug1: fd 3 clearing O_NONBLOCK

[09/12/2021 09:59:02] debug1: Connection established.

[09/12/2021 09:59:02] debug1: key_load_public: No such file or directory

[09/12/2021 09:59:02] debug1: identity file /home/functionaccount/keys/id_dsa type -1

[09/12/2021 09:59:02] debug1: key_load_public: No such file or directory

[09/12/2021 09:59:02] debug1: identity file /home/functionaccount/keys/id_dsa-cert type -1

[09/12/2021 09:59:02] debug1: key_load_public: No such file or directory

[09/12/2021 09:59:02] debug1: identity file /home/functionaccount/keys/id_rsa type -1

[09/12/2021 09:59:02] debug1: key_load_public: No such file or directory

[09/12/2021 09:59:02] debug1: identity file /home/functionaccount/keys/id_rsa-cert type -1

[09/12/2021 09:59:02] debug1: Enabling compatibility mode for protocol 2.0

[09/12/2021 09:59:02] debug1: Local version string SSH-2.0-OpenSSH_7.4

[09/12/2021 09:59:02] debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0

[09/12/2021 09:59:02] debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000

[09/12/2021 09:59:02] debug1: Authenticating to X.X.X.X:22 as 'functionaccount'

[09/12/2021 09:59:02] debug1: SSH2_MSG_KEXINIT sent

[09/12/2021 09:59:02] debug1: SSH2_MSG_KEXINIT received

[09/12/2021 09:59:02] debug1: kex: algorithm: curve25519-sha256

[09/12/2021 09:59:02] debug1: kex: host key algorithm: ecdsa-sha2-nistp256

[09/12/2021 09:59:02] debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

[09/12/2021 09:59:02] debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

[09/12/2021 09:59:02] debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

[09/12/2021 09:59:02] debug1: Server host key: ecdsa-sha2-nistp256 SHA256:IyK62br8gUGDbmHS5C1nPp96a8sPIDvcKxTmDZ6aT/A

[09/12/2021 09:59:02] debug1: Host 'X.X.X.X' is known and matches the ECDSA host key.

[09/12/2021 09:59:02] debug1: Found key in /home/QuestService/.ssh/known_hosts:1673

[09/12/2021 09:59:02] debug1: rekey after 134217728 blocks

[09/12/2021 09:59:02] debug1: SSH2_MSG_NEWKEYS sent

[09/12/2021 09:59:02] debug1: expecting SSH2_MSG_NEWKEYS

[09/12/2021 09:59:02] debug1: SSH2_MSG_NEWKEYS received

[09/12/2021 09:59:02] debug1: rekey after 134217728 blocks

[09/12/2021 09:59:02] debug1: SSH2_MSG_EXT_INFO received

[09/12/2021 09:59:02] debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>

[09/12/2021 09:59:02] debug1: SSH2_MSG_SERVICE_ACCEPT received

[09/12/2021 09:59:02] This system is for the use of authorized users only. Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by sy

stem personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorized users may also be monitored. Anyone using this system expressly consents to such monitoring and is a

dvised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials.

[09/12/2021 09:59:02] debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[09/12/2021 09:59:02] debug1: Next authentication method: publickey

[09/12/2021 09:59:02] debug1: Trying private key: /home/functionaccount/keys/id_dsa

[09/12/2021 09:59:02] debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[09/12/2021 09:59:02] debug1: Trying private key: /home/functionaccount/keys/id_rsa

[09/12/2021 09:59:02] debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[09/12/2021 09:59:02] debug1: No more authentication methods to try.

[09/12/2021 09:59:02] Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

[09/12/2021 09:59:02] Unable to connect to the remote system, permission denied

[09/12/2021 09:59:02] The test of system [HOSTNAME,functionaccount] failed!

[09/12/2021 09:59:03] Processed the system check on HOSTNAME in 0.8260826 seconds

Parents
  • Hi Joshan,

    Seems there is an issue with the Public Key authentication, please make sure the SSH key used is an RSA key:
    https://support.oneidentity.com/tpam/kb/211748/how-to-generate-rsa-keys-for-authentication-on-linux-unix-systems-for-functional-or-privileged-accounts

    Make sure the key is deployed correctly on the target system under the functional account's .ssh directory and that the file name matches what is indicated in the sshd_config file (for example: authorized_keys).

    1. Checking location of authorizedkeyfiles in the sshd_config file:

    # grep -i authorizedkeysfile /etc/ssh/sshd_config

    2. Ensuring public key authentication is enabled 

     # grep -i pubkey /etc/ssh/sshd_config 

    3. If the functional account is root or uid=0 user, verify if PermitRootLogin is set to yes

    4. Typically, the authorized_key file permission should not be writable or readable by any other users and the .ssh directory & home directs are typically, owned by the user. 

    eg.

    chmod g-w /home/funcacct

    chmod 700 /home/funcacct/.ssh

    chmod 600 /home/funcacct/.ssh/authorized_keys

    Thanks!

Reply
  • Hi Joshan,

    Seems there is an issue with the Public Key authentication, please make sure the SSH key used is an RSA key:
    https://support.oneidentity.com/tpam/kb/211748/how-to-generate-rsa-keys-for-authentication-on-linux-unix-systems-for-functional-or-privileged-accounts

    Make sure the key is deployed correctly on the target system under the functional account's .ssh directory and that the file name matches what is indicated in the sshd_config file (for example: authorized_keys).

    1. Checking location of authorizedkeyfiles in the sshd_config file:

    # grep -i authorizedkeysfile /etc/ssh/sshd_config

    2. Ensuring public key authentication is enabled 

     # grep -i pubkey /etc/ssh/sshd_config 

    3. If the functional account is root or uid=0 user, verify if PermitRootLogin is set to yes

    4. Typically, the authorized_key file permission should not be writable or readable by any other users and the .ssh directory & home directs are typically, owned by the user. 

    eg.

    chmod g-w /home/funcacct

    chmod 700 /home/funcacct/.ssh

    chmod 600 /home/funcacct/.ssh/authorized_keys

    Thanks!

Children
No Data