Ok, I'm a spiceworks newbie. Several of my devices have scan errors that say there are no open ports, and suggest it’s a firewall issue.

One device in particular is running Red Hat Linux. From the Spiceworks server, I can SSH into the server using the SSH account I provided to Spiceworks. (So it’s not an IPtables issue.) The server is located on the same subnet as well. Spiceworks does identify the OS as RHEL, but when I look at the finder_re.log, it’s been classified as a Windows server and doesn’t appear to attempt to connect via SSH.

I've deleted the asset and rescanned with the same results. The server is a VMware instance.

For my windows servers, I've created a service account for spiceworks. Since the Linux servers are also joined to the AD domain, I wonder if this causing the issue?

Okay the workaround that we were able to implement, thanks to suggestions from the earlier topic, was to block port 135 from the spiceworks server to the linux box using iptables. After that Spiceworks correctly identified the server.

I would suggest that this is a flaw in spiceworks that it got stuck thinking the system was windows just because 135 was not dropped. Likewise Open uses port 135, and there could be other reasons to use it theoretically. since Spiceworks was able to identify the OS as RHEL, SP 6.0 clearly there are other ways to identify it, and either way it should not get stuck on windows without trying ssh.

Thanks for the reply. Yes, once I configured the account, I selected that account in the scanning section. At first I just tried to use the same credentials for Windows since they are all joined to the domain, and it worked on some of my linux machines. As a test, for this particular server in question, I created a new local account, added it to spiceworks and selected it in the scan. I then tested the account from the Spiceworks server, deleted the device from Spiceworks, and re-ran the scan. It still says there are no open ports upon rediscovery. I think this is because its still was classified as windows for some reason and doesnt even attempt to SSH.

Does anyone else have any insight as to why Spiceworks will corectly ID an OS as Red Hat, yet fail to attempt to connect via SSH and state its a non-responsive windows server that has a firewall problem?

1st Post

Disabling incremental scanning does cause spiceworks to (try to) reclassify the system, but it still classifies it incorrectly and therefore fails the scan. Is there some way to manually change this classification?

Okay the workaround that we were able to implement, thanks to suggestions from the earlier topic, was to block port 135 from the spiceworks server to the linux box using iptables. After that Spiceworks correctly identified the server.

I would suggest that this is a flaw in spiceworks that it got stuck thinking the system was windows just because 135 was not dropped. Likewise Open uses port 135, and there could be other reasons to use it theoretically. since Spiceworks was able to identify the OS as RHEL, SP 6.0 clearly there are other ways to identify it, and either way it should not get stuck on windows without trying ssh.

Anyway at least it is a workaround.

0

This discussion has been inactive for over a year.

You may get a better answer to your question by starting a new discussion.