I created the SSH keys and the public files were put on the target system.
I added the login credentials and tested them against the target system… success.
Submitted a discovery against the target and
getDiviceInfo is OK, but getHostInfo method gives “NoAccessMethod”.
If I look at “Session Results” it says..
Session type: unix login
Successful: no
Status: failed to get login session

Tried SSH from the command line of the Tideway server and got:

[tideway@mrkaddmvm1 ~]$ ssh .(JavaScript must be enabled to view this email address)

Last login: Tue Nov 17 10:15:09 2009 from 172.28.2.250

$ hostname
mrkarsapuxdv01
$

So the SSH keys are ok… but why is the discovery recognizing the login?

First check – when you say you tested the credentials did you do that from the Credential Test feature in the product or by hand?

I tested the credentials via the product first.
When I say the “no logon” message, I had an admin try it by hand.

PS. I downloaded the Community edition last week
i started with two systems…
one Solaris
one AIX (although the tool identified it as MAC OS X)
I then created the ssh keys and had them deployed.
I used the credentials ui to created the account and tested access.
They are both behaving the same.

OK a few more thoughts and checks. My thinking here is to double check that the system is actually finding a credential to use.

1) In the session results do you get a credential key entry as shown in the attached screenshots? If you don’t then the system is not able to find the credential

2) What do you have in the IP Range field for the UNIX credential you are using?

3) Can you send me a screenshot of the credential test started by this process: Discovery tab -> Credentials button -> Credentials Test tabs -> Test IP access In the light box can you enter the IP of the host you are having difficulty with. (feel free to send me the image by pm if you’d rather not post it direct to the forum)

4) When you log on by hand do any of the shells use colour via terminal control characters?

Hmmmm.I can’t seem to screen print, but there is the grab from the screen.
1) no credentials are shown.
Discovery Access:

Method Status Script Access Result
getDeviceInfo OK mrkarsapuxdv01.corp.teranet.ca
getHostInfo NoAccessMethod Discovered Host Information
getInterfaceList NoAccessMethod 0 Discovered Network Interfaces found

Discovery Access>Host Info:

Discovery Method getHostInfo
Discovery duration 0
Request time 17/11/2009 10:27
Failure Reason NoAccessMethod
Discovery Access 172.28.3.77 @ 2009-11-17 10:26:52.66

Discovery Access>Session Results:

Session Type unix login
Successful No
Status Message Failed to get login session
Discovery Access 172.28.3.77 @ 2009-11-17 10:26:52.66

2) 172.*
3)
Credential Tests screen
IP Address Test Type State Submitted By Submission Time Start Time Duration Actions
172.28.3.77 IP Access Success discovery Tue Nov 17 13:30:43 2009 Tue Nov 17 13:30:43 2009 3 seconds Delete | Retry

Test Results screen
IP Range Description Username Options
IP=172.* Patrol ID for SSH patrol Methods=‘ssh,rlogin’Timeout=60.0
Audit Trail
Trying ssh access via user patrol
ssh access succeeded as user patrol

4) no

Just to eliminate one possibility are the target servers listening for ssh on port 22 or are they using a non standard port?

Just the standard port 22.

I think the problem you are having is that either there is a firewall between your appliance and the target host or the hosts themselves have been hardened. The misidentification of AIX/MAC OS on the credentialess scan could also be another symptom of this.

During full discovery the system will look to see what ports are open on a target host in order to select what credentials it has that will work. I think we are not seeing that the port is open when we do that and therefore not selecting the credential. The normal issue is that the IP ranges/regexes aren’t right but we’ve checked those.

Clearly the port is open as you can connect from the CLI account. In fact you’ve pretty much done all the tests I’d run through :) So what we need to do is to tell the system to be a little less strict in checking ports.

If you go to Administration -> Discovery Configuration and then look at the “Valid Port States” setting it should have “open|filtered” enabled but not “filtered”. Try setting “filtered” as well and I hope that will clear the issue.

Note that setting this may reduce the performance so if this is a situation unique to your test environment you may wish to review your approach if you move to a full deployment.

Let me know how it goes.

That did it.

Can you explain “filtered” a bit more, so I can discuss firewall rules with our network team?

Thanks again

Ah so a firewall was involved :)

Here are the breakdowns of the states. In a larger roll out you probably would want to avoid running with the “filtered” enabled if you could avoid it. There are a number of deployment options which you could consider if you decide to do that.

“open” – we are able to send packets to the port and get a response back
“open|filtered” – we are able to send packets to the port but do not expect to get a response back from that port hence it is indeterminate if it is open or filtered.
“filtered” – we are unable to confirm we can send packets to the port, either no response is received or the responses indicate communication errors. This can be because of active protection of the port by firewalls or routers, or because of genuine network errors.