Scan of the Linux Server fails with "No Access" when credentials are configured with SSH key, credentials test fails as well , the issue is seen in discovery appliance or outpost An SSH key is an access credential in the SSH protocol Authorized keys are public keys that grant access Identity keys are private keys that an SSH client uses to authenticate itself Authorized keys and identity keys are jointly called user keys. SSH keys are typically configured in an authorized_keys file in .ssh subdirectory in the user's home directory |
Root cause 1: The authorized (or public) key is not copied onto the target server affected by this issue. To confirm:
If the file ~/.ssh/authorized_keys in the scanned device is empty, the root cause is confirmed. If public key is not found in file ~/.ssh/authorized_keys in the scanned device, the root cause is confirmed
grep -f <public key file> ~/.ssh/authorized_keys
Root cause 2: The AuthorizedKeysFile attribute was customized in the target server To confirm:
As root, execute the command below (in the target server)
grep AuthorizedKeysFile /etc/ssh/sshd_config If the value is not set to .ssh/authorized_keys, the root cause is confirmed. Root cause 3: The authorized_keys file should be owned by the user on the remote system. In addition, the user should have read and write permissions. To confirm: Verify owner and permissions with following command
ls -l .ssh/authorized_keys
Owner must be user the connection attempt is made from and permissions must be rw
Solution: Change user and permissions using following commands
sudo chmod 600 ~/.ssh/authorized_keys
sudo chown <user> ~/.ssh/authorized_keys
Root cause 4: Network issue (The ssh client can't reach the ssh server) To confirm:
On target system: verify ssh port in use (default is 22 but this can be customized):
grep -i port /etc/ssh/sshd_config
From appliance CLI (or the outpost) affected by this issue, verify port 22 (or customized one) is reachable:
nmap -p 22 <targetip>
Update the ssh port if needed. If nmap reports that the ssh port is closed, the root cause is confirmed. If the port is filtered, the root cause is still very probable. If it's open, the root cause is eliminated.
Root cause 5: The authorized (public) key or identify (private) keys are invalid To confirm:
If the credential affected by the issue is in the appliance:
- Copy the identity (private key) onto the appliance (for example in /usr/tideway/id_rsa).
- Change file permission to 600 (chmod 600 /usr/tideway/id_rsa) - Run this command to check SSH connectivity: ssh -i /usr/tideway/id_rsa <user>@<target_Server_IP> -v
Where <user> is the user configured in the Discovery Unix credential and <target_Server_IP> is the IP of the target server.
If the credential is in an outpost, test can be done using command prompt: - Copy the identity (private key) onto the Outpost server (for example in C:\Users\<your user>\id_rsa).
- Change file permission to only allow read and execute access to your user. - Open Command Prompt (cmd) and run this command to check SSH connectivity: ssh -i C:\Users\<your user>\id_rsa\id_rsa <user>@<target_Server_IP> -v
Where <user> is the user configured in the Discovery Unix credential and <target_Server_IP> is the IP of the target server.
If the test fails, the root cause is confirmed. Solution: Re-generate the public/private keys with a generic procedure (like this one for example) and deploy them in both client/server. Root cause 6: defect DRUD1-42631 fixed in TKU Nov23 To confirm:
If the same test credential works from the appliance and fails from the outpost, the root cause is confirmed.
Solution: upgrade the TKU to Nov23 and upgrade the outpost |