- Setting up Linux/Unix auto-discovery
- Discovery Job Options Definitions
- Naming Options
- Configuring SSH key auth for discovery
- Configuring Linux Hostname Discovery Details
- Run *Nix SSH discovery
- Linux Considerations
- Linux Permissions
- SUDO PATH in non-interactive shells
Device42 supports SSH-based Linux and UNIX discovery from within the main appliance (v13.2+). For a full list of supported Linux/UNIX operating systems please visit Device42 Supported Operating Systems
Setting up Linux/Unix auto-discovery
Prior to configuring an ssh-based discovery job, please be sure you have your SSH port (standard TCP port 22, or a custom port) open between your Device42 Main Appliance or Remote Collector and the targeted Unix/Linux servers.
From the main menu, “Discovery → Hypervisors/nix/win”*, you can add a Linux/UNIX discovery job to connect and gather host and VM details. On the “Add Hypervisors/*nix/win for Autodiscovery” page, choose *nix as the platform, enter your discovery target [hostnames, IP(s) or IP range(s), or CIDR], credentials, and job options:
Discovery Job Options Definitions
Job Name: User defined name for the job.
Remote Collector: Select which remote collector you’d like to run the discovery job from – optional.
Discovery Target(s): Specify FQDN or IP of discovery target(s). If using FQDN, Device42 must be configured to resolve DNS.
Port: This will be 22 by default. Only change if you have a different ssh port configured.
Use telnet if SSH port is closed: Fall back to telnet (port 23) if SSH port is found to be closed.
Username & password: self explanatory. Use username with permission to connect to the Linux/Unix targets with SSH.
Enable Resource Utilization Tracking for Device(s): Optionally enable collection of resource utilization metrics from discovered devices.
Resource Utilization Sampling Interval: Set the interval for RU data collection; only has effect if RU is enabled.
Schedule for auto-discovery: You can schedule the discovery to run at certain times.
WARNING: Please do not set up an auto-discovery / scan using critical production account credentials!
Depending on permissions granted & your configured password policies, account lock-out could result in an otherwise completely avoidable outage. You, the customer, are responsible for any such behavior that might result if you choose to ignore this requirement.
Strip domain suffix: strips the domain suffix from discovered servers – [see the next section for hostname config details].
Domains to strip: Ordered list of domains to strip from hostname, one per line – if blank, full domain stripped; if specified, first match is stripped.
Set device name as name given in the server field of auto-discovery job: if checked & discovering via hostname/FQDN, device will be named using discovery target name provided.
Overwrite existing device hostname with discovered hostname : Check this option to give precedence to the discovered hostname.
Device Name Format: select desired device naming format; see “Configuring hostname discovery details” below for explanations.
Exclude Server(s): List of server IPs to exclude from discovery – [Useful to ignore individual IPs when discovery target specified as range or CIDR block]
Exclude Service Port Client IPs: do not discover client connections on specified listening ports.
Remote IP Exclusion: do not discover any connections to/from any of these remote IPs.
Debug Level : Debug On for extra debug info, useful for a support ticket.
The remaining options are geared toward hypervisor discovery and can be ignored for Linux/UNIX discovery.
Configuring SSH key auth for discovery
SSH keys can be used for Linux discovery in lieu of a password. Setting up discovery to use an SSH key is a simple two-step process, and even easier if your servers are already configured for SSH-key access – If you can already use an SSH key to log on to your servers with the desired discovery user account, grab your SSH private key & start with Step2!
- Ensure your Linux target servers are configured for SSH public key auth, and if not, configure them
- Add your SSH RSA (or DSA) Public key to a credential in Device42, and use that credential to configure your discovery job otherwise as you always have
Supported SSH key ciphers
The following ciphers are supported by Device42 for SSH-key based discovery authentication:
Configure discovery target servers for SSH Public key authentication
1) Ensure Linux target servers are configured for SSH public key authentication
You can create a new key pair, or if you’d prefer, you may use an existing SSH keypair. To create a new key:
a. Generate an RSA key pair using ssh-keygen:
ssh-keygen -t rsa
Generating public/private RSA key pair. Enter file in which to save the key (/Users/vivek/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/vivek/.ssh/id_rsa. Your public key has been saved in /Users/vivek/.ssh/id_rsa.pub. The key fingerprint is: 80:5f:25:7c:f4:90:aa:e1:f4:a0:01:43:4e:e8:bc:f5 vivek@desktop01 The key's randomart image is: +--[ RSA 2048]----+ | oo ...+. | |.oo . .ooo | |o .o. . .o . | | o ...+o. | | o .=.=S | | . .Eo . | | | | | | | +-----------------+
Note that ssh-keygen will ask you to set the Key Pair location and name. You may use the default location if you do already have another key there or are OK with it being overwritten [e.g. $HOME/.ssh/id_rsa]. You will also be prompted to supply a passphrase (password) for your new private key. This is OPTIONAL, and you can leave it blank if you choose.
The folowing two files were created by the command you just ran:
$HOME/.ssh/id_rsa– contains your private key. $HOME/.ssh/id_rsa.pub – contain your public key.
Go ahead and save a copy of the id_rsa file (this is your private key) somewhere local (somewhere you are able to browse to so you can upload it to Device42).
b. Use $ssh-copy-id to copy the newly generate certificate to your target host(s):
ssh-copy-id -i $HOME/.ssh/id_rsa.pub email@example.com
This sets up your target hosts for remote SSH-key based auth using the same user account you used to run the command. If you used ssh-copy-id, you’re all set to test your SSH-key auth. Verify your SSH key-based login works from a remote terminal, and once verified, proceed to Step 2, and set up your Linux discovery job (or, optionally, modify an existing one).
Optionally, instead of ssh-copy-id, you can log onto these servers and do this manually.
Should you choose to do it manually, you must create the .ssh directory in the users home directory you’ll be using for discovery and the authorized_keys file within. Substitute $HOME with your discovery user’s username, and set the permissions as follows.
mkdir -p $HOME/.ssh
chmod 0700 $HOME/.ssh
Then simply create the file $HOME/.ssh/authorized_keys if it doesn’t already exist, and to copy & paste the newly generated public key (copy the text of the entire file) on a new line in the authorized_key file. It will look something like this:
Create a discovery job that uses SSH key auth
2) Add your private SSH RSA or DSA Private key that (created in Step 1) to your Device42 instance’s discovery job.
Simply set up a new discovery job as you always have, (Discovery -> HyperVisors / *nix / Windows -> Add Hypervisors/*nix/win for Autodiscovery), this time selecting a credential for the job’s “Username/Password(s)” field that includes the SSH key file (id_rsa) attached instead of a password, as shown below. You may add the file ahead of time (Secrets menu -> “Add Password” button), or during job setup:
You’re all set to run Linux discovery using an SSH key!
Save and Run your discovery job! Device42 will use the SSH key instead of a password!
*Note* – if you chose to set a password for your SSH key, simply check the “Use Password” box and supply the SSH key file’s password as well as the ssh key! Note that you can do this after the fact by editing the credential you created. You are also able to download the keyfile you used (circled):
Configuring Linux Hostname Discovery Details
When discovering a device name, the first command we check is “hostname”. This is used to derive the short name of the host.
After running hostname, we’ll run the following commands to obtain the domain name. They’re ordered by which command’s results we give the most weight to:
If we don’t get a domain name with any of those commands we’ll try “cat /etc/resolv.conf” last. In this case we’ll split on the white space in the file and look for a “domain” token. When we see one, we’ll assign domain as the 2nd token after “domain”.
Strip Domain Suffix
When selected, Device42 will drop everything after the first “.” in the device name.
For naming options, the above mentioned Strip Domain Suffix option occurs prior to assigning the device name according to the naming option you choose. The naming options are as follows:
- Hostname as discovered – if domain is present and domain is not in the name it is set to “name”
- Hostname Plus Domain Name and Add Host name as Alias – alias is set to “name” and the device name becomes “name.domain”
- Hostname Plus Domain Name the device name becomes “name.domain”
- HostnameAddHostnamePlusDomainNameAlias names stays the same and a alias is set as “name.domain”
Run *Nix SSH discovery
Upon save(if you haven’t scheduled the discovery), you can run it from list, view or edit page using “Run now” button or link.
You can schedule the auto-discovery to run on a recurring basis. Specifically, you can choose to have it run on certain days of the week and at a specific time each day.
Linux Auto-discovery has been tested against Redhat, Debian, CentOS, Ubuntu, and Oracle distributions and should work fine against just about all similar Linux distributions that have python installed.
Confirm this by checking to see if your platform supports the following commands:
OS: /usr/bin/python -m platform
Manufacturer, Hardware and Serial # : sudo /usr/sbin/dmidecode -s system-manufacturer (and system-product-name, system-serial-number)
IP Info: /sbin/ifconfig -a
CPU Info: from /usr/sbin/dmidecode
There are several commands that are run as part of the Linux autodiscovery process that, by default, typically require root privileges. We do extensive testing to see which commands we can run without sudo while still obtaining all available information. The following is a table of commands we sometimes or always run as sudo. For the “Sometimes” commands, we’ll try to run the command first without, and if we receive a permission denied command rather than an “invalid command”, “command not found” or similar we’ll attempt to run as sudo. This list will also say if it’s run on every Linux/UNIX flavor or only certain platforms:
|Command||Run with sudo?||OS flavor|
|su $oracle_user||Sometimes||Discovers Oracle application information by running necessary commands as the Oracle user|
|su $sap_hana_user||Sometimes||Discovers SAP HANA application information by running necessary commands as the SAP user|
|zlogin||Always||Solaris (For Zones)|
Note, these commands sometimes change so please check with Device42 for the current list.
Below you can see an example of how to allow a particular user or group to run a specific sudo command without being prompted for a password:
**%your-group-here ALL = (ALL) NOPASSWD:/usr/sbin/dmidecode, /sbin/hdparm, /sbin/fdisk**
Adjust the above paths as needed to match the location of each program. If these permissions are missing, the auto-discovery client will not be able to discover hardware, manufacturer, serial #, and so on, as well as service dependencies and valuable application configuration information.
You might also have to comment out the Default Require tty in the /etc/sudoers file.
SUDO PATH in non-interactive shells
If users are experiencing Linux discoveries where Device42 is using a non-interactive shell rather than interactive, we may be trying the commands multiple times because PATH is not set in non-interactive shells. The users can set that information in their sudoers file for the service account to prevent these commands from being executed multiple times. It should be there by default, but sometimes it’s commented out or removed for security hardening.
It’s not a bug, but some deployments may see security alerts for invalid commands being executed because of this.
In sudoers, there should be a line as follows:
You could alternatively make the defaults particular to just the discovery account like so: