Rho does not scan with second auth in profile

[mdvickst]

Opening a new issue

---

Specify type:

• Bug

Bug severity (if applicable):

• Blocker

  ---

Description:

If a profile is created with 2 auths, if the first auth does not work on any systems the second ping scan is not performed with the second auth.

---

Bug Report

Version of rho:

[0.0.31 ]

Expected behavior:

It should scan all non-successful connections from the first ping scan with auth 1, in this case all IPs were unsuccessful so it should have scanned all IPs.

Actual behavior:

It says it is scanning with second auth but it doesn't actually scan.

Found 256 unreachable systems.

Attempting connection discovery to 0 systems with auth "test_root" using a timeout of 5 minutes.
All auths are invalid for this profile

Steps to reproduce:

rho auth add --name ssh_key_1 --username mvickstr --sshkeyfile /root/.ssh/id_rsa rho auth add --name test_root --username root --password rho profile add --name test_2_auth --hosts 192.168.56.0/24 --auth ssh_key_1 test_root rho scan --profile test_2_auth --reportfile 2auth.csv

ssh_key_1 is an auth that will not work on any system test_root is an auth that will work on at least 1 system

[chambridge]

I tried to reproduce:

$ rho scan --profile i576 --reportfile i576.csv
Please enter your rho vault password: 
Connection discovery will be perform with the following auth credentials: bad, master
Note: Any ssh-agent connection setup for a target host will be used as a fallback if it exists.

Attempting connection discovery to 1 systems with auth "bad" using a timeout of 5 minutes.
Failed to connect with auth "bad" to 1 systems.

Attempting connection discovery to 1 systems with auth "master" using a timeout of 5 minutes.
Connection succeeded with auth "master" to 1 systems.

Scan will be performed against 1 of 1 systems.

Starting scan of 1 systems broken into 1 groups.

....

Processing scan data for 1 more systems.
Completed scanning 1 systems.

Scanning has completed. The mapping has been stored in file '/Users/christopherhambridge/.config/rho/i576_host_auth_mapping'. The facts have been stored in '/Users/christopherhambridge/Code/rho/i576.csv'

The fact that your example says Found 256 unreachable systems. is what bothers me as we differentiate between Failed and Unreachable systems.

Can you attach the log?

[mdvickst]

logs.zip

[mdvickst]

It looks like the customer's system was "unreachable too" but both of us have successful logins when we use only the auth that works....

Attempting connection discovery to 1 systems with auth "primary_auth_profile_with_sshkey" using a timeout of 5 minutes.

Found 1 unreachable systems.

[chambridge]

@mdvickst I'm unable to reproduce this. I will need to jump on to your subnet to try and debug. I've attempted against 10.10.181.0/24 but each time It has successfully processed through to the second credential. I see in the logs you provided that the systems that usually respond were found in the unreachable set. So ansible got an UNREACHABLE from the output of the ping, seems weird unless there was some networking issue or the systems go up and down.

[chambridge]

So I was able to reproduce ... it seems its specific to using a bad credential with an sshkey. I tailed the log and saw the following response where Ansible appears to be treating Permission denied as unreachable as opposed to failed which occurs with a password:

10.10.181.105 | UNREACHABLE! => {
    "changed": false, 
    "msg": "Failed to connect to the host via ssh: chris@10.10.181.105: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n", 
    "unreachable": true
}