Reset password fail of some systems

Hello Team,
I am getting an alerts to reset password fail of some systems.
When i check the test system is succesful and while checking the functional acccount password
I am getting the below error:-
For the troubleshooting:-
We have match the key that is managed by the system it is availble in system as well.
[07/04/2021 10:19:58] Gathering the check details for svcpam on hvach02...
[07/04/2021 10:19:58] Retrieving the password hash for svcpam on hvach02 (Solaris System) using svcpam...
[07/04/2021 10:19:59] spawn -nottyinit /usr/bin/ssh -v -t -2 -l svcpam -i /home/edmzpar/keys/RSAprivate -i /home/edmzpar/keys/id_dsa -i /home/edmzpar/keys/hpux_dsa -p 22 -o BatchMode=yes -o PasswordAuthentication=no -o ConnectTimeout=60 10.1.33.132 grep s
vcpam /etc/shadow
[07/04/2021 10:19:59] OpenSSH_7.4p1, OpenSSL 1.0.2j 26 Sep 2016
[07/04/2021 10:19:59] debug1: Reading configuration data /etc/ssh_config
[07/04/2021 10:19:59] debug1: Connecting to 10.1.10.10 [10.1.10.10] port 22.
[07/04/2021 10:19:59] debug1: fd 3 clearing O_NONBLOCK
[07/04/2021 10:19:59] debug1: Connection established.
[07/04/2021 10:19:59] debug1: key_load_public: No such file or directory
[07/04/2021 10:19:59] debug1: identity file /home/edmzpar/keys/RSAprivate type -1
[07/04/2021 10:19:59] debug1: key_load_public: No such file or directory
[07/04/2021 10:19:59] debug1: identity file /home/edmzpar/keys/RSAprivate-cert type -1
[07/04/2021 10:19:59] debug1: key_load_public: No such file or directory
[07/04/2021 10:19:59] debug1: identity file /home/edmzpar/keys/id_dsa type -1
[07/04/2021 10:19:59] debug1: key_load_public: No such file or directory
[07/04/2021 10:19:59] debug1: identity file /home/edmzpar/keys/id_dsa-cert type -1
[07/04/2021 10:19:59] debug1: key_load_public: No such file or directory
[07/04/2021 10:19:59] debug1: identity file /home/edmzpar/keys/hpux_dsa type -1
[07/04/2021 10:19:59] debug1: key_load_public: No such file or directory
[07/04/2021 10:19:59] debug1: identity file /home/edmzpar/keys/hpux_dsa-cert type -1
[07/04/2021 10:19:59] debug1: Enabling compatibility mode for protocol 2.0
[07/04/2021 10:19:59] debug1: Local version string SSH-2.0-OpenSSH_7.4
[07/04/2021 10:19:59] debug1: Remote protocol version 2.0, remote software version OpenSSH_8.1
[07/04/2021 10:19:59] debug1: match: OpenSSH_8.1 pat OpenSSH* compat 0x04000000
[07/04/2021 10:19:59] debug1: Authenticating to 10.1.10.10:22 as 'svcpam'
[07/04/2021 10:19:59] debug1: SSH2_MSG_KEXINIT sent
[07/04/2021 10:19:59] debug1: SSH2_MSG_KEXINIT received
[07/04/2021 10:19:59] debug1: kex: algorithm: curve25519-sha256
[07/04/2021 10:19:59] debug1: kex: host key algorithm: ssh-rsa
[07/04/2021 10:19:59] debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[07/04/2021 10:19:59] debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
[07/04/2021 10:19:59] debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
[07/04/2021 10:19:59] debug1: Server host key: ssh-rsa SHA256:kDhUhegXc0JcaEP4uT27OkZPogezBMAM12CCQMiTTQo
[07/04/2021 10:19:59] debug1: Host '10.1.10.10' is known and matches the RSA host key.
[07/04/2021 10:19:59] debug1: Found key in /home/QuestService/.ssh/known_hosts:45
[07/04/2021 10:19:59] debug1: rekey after 4294967296 blocks
[07/04/2021 10:19:59] debug1: SSH2_MSG_NEWKEYS sent
[07/04/2021 10:19:59] debug1: expecting SSH2_MSG_NEWKEYS
[07/04/2021 10:19:59] debug1: SSH2_MSG_NEWKEYS received
[07/04/2021 10:19:59] debug1: rekey after 4294967296 blocks
[07/04/2021 10:19:59] debug1: SSH2_MSG_EXT_INFO received
[07/04/2021 10:19:59] 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>
[07/04/2021 10:19:59] debug1: SSH2_MSG_SERVICE_ACCEPT received
[07/04/2021 10:19:59] debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
[07/04/2021 10:19:59] debug1: Next authentication method: publickey
[07/04/2021 10:19:59] debug1: Trying private key: /home/edmzpar/keys/RSAprivate
[07/04/2021 10:19:59] debug1: Authentication succeeded (publickey).
[07/04/2021 10:19:59] Authenticated to 10.1.10.10([10.1.10.10]:22).
[07/04/2021 10:19:59] debug1: channel 0: new [client-session]
[07/04/2021 10:19:59] debug1: Entering interactive session.
[07/04/2021 10:19:59] debug1: pledge: network
[07/04/2021 10:19:59] debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
[07/04/2021 10:19:59] debug1: Sending command: grep svcpam /etc/shadow
[07/04/2021 10:19:59] debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
[07/04/2021 10:19:59] debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
[07/04/2021 10:19:59] debug1: channel 0: free: client-session, nchannels 1
[07/04/2021 10:19:59] Connection to 10.1.10.10 closed.
[07/04/2021 10:19:59] Transferred: sent 2472, received 5248 bytes, in 0.3 seconds
[07/04/2021 10:19:59] Bytes per second: sent 9887.4, received 20990.8
[07/04/2021 10:19:59] debug1: Exit status 0
[07/04/2021 10:19:59] The password for hvach02/svcpam in TPAM DOES NOT MATCH the managed system!
[07/04/2021 10:20:00] Processed the password check for svcpam on hovachw02t in 1.0160581 seconds

can anyone help me on this how we can solve this issue?
Parents
  • Hello,

    In reviewing the output you have provided, it looks like TPAM is able to contact the system and authenticate successfully with a public key.

    It them attempts to run the following command:  grep svcpam /etc/shadow

    Perhaps it had an issue reading the shadow file (which would be necessary to check the password)

    Is it possible to try logging on to this target system directly with the same functional account credentials, and then see if you are able to run the same command directly on the system? If not, it may be a permission issue?

    Clint

Reply
  • Hello,

    In reviewing the output you have provided, it looks like TPAM is able to contact the system and authenticate successfully with a public key.

    It them attempts to run the following command:  grep svcpam /etc/shadow

    Perhaps it had an issue reading the shadow file (which would be necessary to check the password)

    Is it possible to try logging on to this target system directly with the same functional account credentials, and then see if you are able to run the same command directly on the system? If not, it may be a permission issue?

    Clint

Children
No Data