How to discover SSH Servers by port other than 22

Issue

This article describes two ways to configure Discovery to discover SSH Servers on ports other than the default 22.

Note: Throughout this KB we will use port 22000 as an example. However, this port can be changed to the port that best fits the environment (the port where SSH devices are listening on). Thus, wherever you see "22000", replace it with the desired port.

Release

All

Resolution

Adding an IP Service

Go to "Discovery Definition > IP Services" and add a New entry with the following information:
- Name: SSH on 22000
- Service name: Secure Shell Service on 22000
- Port: 22000
- Protocol: TCP
- Creates: None
Go to "Discovery Definition > Port Probes" and edit the entry "ssh"
- Unlock the field "Triggered by services"
- Add "SSH on 22000" to it
- Save the Discovery Port Probe.

The next time you run Discovery, by default both ports 22 and 22000 will be scanned. The port that answers will be the one used for the SSHCommand probes triggered through the rest of the discovery. The only disadvantage is that both ports 22 and 22000 will be scanned for each scan.

In a very special situation, it can also be that both ports 22 and 22000 are available, both with an SSH server but you want the one on 22000 to be used. These disadvantages can be worked around by using Behaviors.

Using Behaviors

Go to "Discovery Definition > IP Services" and add a New entry with the following information:
- Name: SSH on 22000
- Service name: Secure Shell Service on 22000
- Port: 22000
- Protocol: TCP
- Creates: None
Go to "Discovery Definition > Port Probes" and add a new entry (this is almost a copy of "ssh"):
- Name: SSH on 22000
- Description: Secure Shell on 22000 Login
- Scanner: Generic TCP with Banner
- Triggered by services: SSH on 22000
- Triggers probe: UNIX - Classify
- Use classification: UNIX Classification
- Classification priority: 2
- Active: true
- CIs: true
- IPs: true

When Discovery starts a discovery process it sends the Shazzam probe that includes, by default, the Port Probes defined in the Functionality Definition "All".

The Functionality Definition "All" includes by default:

wmi
snmp
ssh
http
wins
dns
printer
osx
ip_phone
slp
wbem

If you know that you want to discover ONLY devices that are listening on 22000, you could create a Functionality Definition that includes only "SSH on 22000" (or even both "ssh" and "SSH on 22000"). Then you just need to create a Behavior that uses that functionality and when you run a Discovery Schedule tell it to use that behavior.

The Discovery Schedule will discover only devices that are in that behavior/functionality.

Go to "Discovery Definition > Functionality Definition" and add a New entry
- Name: SSH on 22000
- Port probes: SSH on 22000
In case you want both 22 and 22000, you could call this functionality definition "SSH MyName" or whatever and include both port probes "ssh" and "ssh on 22000".
Go to "Discovery Definition > Behavior" and add a New entry:
- Name: Ssh Ipsos
- Save
- Open the entry and add a new entry in the related list "Discovery Functionality":
  - Phase: 0
  - Functionality definition: SSH on 2000 (the name used in step 3)
  - MID servers: Add the MID server (1 or more) to run this functionality.
In your Discovery Schedules, set the field Behavior to "SSH NyName".
That would cause that when the schedule starts, the Shazzam probe sent will only scan the ports corresponding to the Port Probes included in the Functionality Definition as explained in step 3).

Observe that the field "MID server" disappears from the Discovery Schedule. That is so because you already indicated what mid server(s) have to process this schedule.

All this has a lot of flexibility and of course, there is more to consider, especially when mid servers are set up in a load-balancing cluster.

Patterns

If the device being discovered makes use of patterns, also add MID server property mid.sa.ssh.port:

Navigate to ecc_agent_property table
Click new
Set name to mid.sa.ssh.port
Set value to a comma separated list of ports
Set the MID server to empty for the property to take effect on all MID servers or specify a MID server

Note: If the environment is hybrid, meaning there are devices listening on 22 or 22000, set the property value to 22,22000.

Probes triggered by sensor

Some sensors may trigger additional probes and not pass the "port" parameter. If this happens, the triggered probes will default to port 22. In such case, the code in the sensor needs to be updated to pass the "port" probe parameter.

Out of box, the following probes come into this issue:

<instance>.service-now.com/discovery_sensor_list.do?sysparm_query=scriptLIKETriggerProbe%5Ereacts_to_probe.ecc_queue_topic%3DSSHCommand

An entry on table ip_service_affinity will be create showing the port used to successfully discover the device once successfully discovered on the alternative port and system property glide.discovery.ip_service_affinity = true. This can be used in order to add the port to such probes triggered from within a sensor. Example code to be added:

var ip = this.getSource();
var sa = new GlideRecord('ip_service_affinity');
sa.addQuery('ip_address',ip);
sa.query();

// If we find an affinity, get the port and add to the probe as a parameter
if(sa.next()){
    // Check that ip_service and ip_service_port are not empty, to avoid any potential nullpointers
    if(!gs.nill(sa.ip_service) && !gs.nill(sa.ip_service.port)){
        // Now that we have the port, lets add it to the probe
        probe.addParameter("port", sa.ip_service.port);
    }
}

There is a attached update set on this KB with the changes necessary to OOB sensors. If you decide to use the update set, please test in a non-production environment first.