Rho doesn't enforce the SSH key used by Ansible

[elyezer]

Specify type:

• Bug

Bug severity (if applicable):

• Medium

---

Description:

Rho can think that a SSH key is valid even though it is not. When the user create an auth credential with a SSH key path rho does not validate if the path is valid (exists on the system) and configure the ping-inventory with the specified key, which is expected. The problem is when the path is not valid, but the user has some keys added to the SSH agent, so rho will configure Ansible to use an specified key but Ansible will actually delegate the connection to the SSH client which will rely on SSH agent to connect to a given system.

That will confuse the user and will produce invalid mappings. For example If the user configure rho with either an invalid SSH key path or a SSH key which is not accepted by a system but has in its system's SSH agent the key which can access that system rho will create the mapping: <invalid_ssh_key> -> .

Other scenarios can happen, another example is when the user has two valid SSH keys (both on rho and SSH agent) but all the mappings will be done with the first credential entry because under the hood the SSH client will resolve the key even when the first is not valid.

---

Bug Report

Version of rho:

07ab01b

Expected behavior:

rho should restrict Ansible connection to only use the specified SSH key or fail if it is not accepted.

Actual behavior:

rho configure Ansible with an SSH key path but it does not ensure that key is valid and is the one that was actually used to connect to a given system.

Steps to reproduce:

Scenario 1: Make sure you have a valid SSH key added to SSH agent and create an auth credential pointing to an invalid path, for example, /not/a/valid/path and try to perform a scan. The scan will be done because a valid key is added to the SSH agent and that will be used.

Scenario 2: Create a new SSH key outside the ~/.ssh/ directory (this will prevent the SSH agent to automatically add the key), this key should access systemA. Make sure another key is created and added to the SSH agent, this key should access systemB. Create a network profile which include both systems but only create one auth credential configured with the first SSH key. Perform a scan, both servers will be accessed, even though the expected would be that only systemA was scanned.

Environment information:

Linux system running SSH agent

[elyezer]

@kdelee let me know if you have any additional comment to this issue. Thank you for helping catching it.

[kdelee]

@elyezer
I have tried a few permutations of this.

This bug does not occur if:

• ALL the auths your provided are username/password based
• NONE of the auths you provided use the same username as your "good" ssh key present in the ssh-agent

This bug does occur if:

• ONE the auths you provided uses an ssh key
• ONE of the auths have the same username as the login name of the "good" sshkey added to your ssh client.
  • this is very plausible
  • does not have to be the ssh key auth

The worst-case scenario I can think of this popping up in is if a user does the following:
SysAdminA decides they want/need to run a scan on a collection of servers in a subnet.
They know that all the servers they want to scan are accessible with sshkey1, and others another set are accessible wish sshkey2. So they create a profile, profile1 with an ip range like 10.10.181.[0:255] and an auth using sshkey1.

They run the scan on profile1 the and come to find that they scanned machines that they should not have had access to...i.e. they were expecting to scan 20 servers and they scan 100. This could

1. interrupt normal operations on the machines that were not scanned intentionally
2. end up causing a much longer scan than expected
3. upset the user when they realize their credentials were used without their explicit permission