Network Inventory User's Guide

Linux and Mac Direct Network Scan

Incorrect SSH Protocol Configuration for Linux and Mac

The Direct Network Scan of Linux and Mac computers, Network Inventory establishes connection to the audited computers using the Secure Shell protocol (SSH). By default, the standard TCP port 22 is used. However, you can supply a different port number when you specify audit credentials.

INFO: For details, see Auditing Individual Network Nodes and Linux and Mac Audit Credentials.

Make sure that all remote computers have the SSH server running. Otherwise, the Direct Network Scan will fail.

If you want to use a SSH private key instead of a password, make sure the SSH public/private key pair is properly set up and the public key is uploaded to all Linux and Mac computers you want to audit. For more information on SSH public key authentication, see https://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter8.html.

Incorrectly Recognized Operating System

Before starting the Direct Network Scan, Network Inventory performs the discovery operation to enumerate computers within the specified audit scope. An important phase of discovery is the identification of the computer's operating system, because the operating system type determines how Direct Network Scan, Network Inventory will later audit the computer.

NOTE: Computers with unrecognized operating systems can still be audited only if you assign the appropriate Audit Credentials.

There can be rare cases when the operating system of a Linux or Mac computer is recognized incorrectly or remains unrecognized. Specifically, a Linux machine running a Samba service sometimes may be recognized as a Windows computer. In this case, the computer cannot be audited. You can solve this problem by changing the operating system type by hand:

  1. In the Network Inventory application, in the All Nodes grid, locate the problematic computer and double-click this record. The Audit Properties [Node Name] dialog box opens.

  2. Review the OS Type field value. If you need to correct it, select a value from the drop-down list.

  3. Click OK.

  4. Audit the computer again.

Extended hardware information is not collected

In order to access low-level hardware information (hardware serial numbers and asset tags) from a Linux system during the Direct Network Scan, the user account used for auditing the system must have root privileges. This is due to the fact that this information is retrieved from the BIOS storage and root privileges are required to get access to the BIOS. The implementation of the Direct Network Scan relies on the dmidecode command to read BIOS data hence root privileges are only required to run this command.

INFO: For details, see Linux and Mac Audit Credentials.

If you want to collect extended hardware information, make sure that dmidecode is installed on each Linux computer you want audited. You may need to install the dmidecode package via your Linux package manager.

Some administrators consider providing credentials for the root account a security risk. The instructions below provide two methods of configuring the dmidecode command to run with elevated (root) privileges, which allows the Direct Network Scan to collect extended hardware information using audit credentials for a non-root account. These instructions have been tested using the Ubuntu Linux distribution. For other distributions the procedure should be very similar.

Setting the setuid bit on the dmidecode file

  1. Log in to the client Linux machine.

  2. Open a console dialog box.

  3. Find the dmidecodefile (typically, it is in the /usr/sbin/ folder):

    which dmidecode

  4. Get root privileges. For example:

    sudo su

  5. Make sure the dmidecode file is owned by root:root:

    ls -l /usr/sbin/dmidecode

    If it is, the output will contain "root" twice. For example:

    -rwxr-xr-x 1 root root 42812 2008-04-04 02:42 /usr/sbin/dmidecode

    If it is not, set the ownership to root:root:

    chown root:root /usr/sbin/dmidecode

  6. Set the setuid bit for the dmidecode file:

    chmod 4755 /usr/sbin/dmidecode

    After doing this, any users or processes running the dmidecode file will have permissions of its owner, within the executed process. Since the owner is set to root, dmidecode will run with root privileges.

  7. Test that the dmidecode command runs as root under a non-root user account. For example, by running the following:

    dmidecode -u

    If dmidecode runs as root, this command will return SMBIOS data.

    IMPORTANT: The setuid bit is disabled on many Linux implementations due to security reasons. If dmidecode does not run as root with the setuid bit set, chances are that your Linux distribution has setuid disabled.

Using the sudo command

The sudo command offers another approach to giving users root access. When trusted users precede an administrative command with sudo, they are prompted for their own password. Once authenticated, the administrative command is executed as if by the root user, assuming the command is permitted.

However, sudo can be configured not to ask for the user's password.

In order to run the dmidecode command with root privileges using the sudo approach, a bit of tweaking is needed:

  1. Log in to your Linux machine and open a console dialog box.

  2. Get root privileges. For example:

    sudo su

  3. Find the location of your sudo and dmidecode files. Typically, they are both in the /usr/sbin folder:

    which sudo
    which dmidecode

  4. Add the user account that you intend to use as a dedicated audit account to the sudoers list on the client Linux machine. To do so, edit the /etc/sudoers file and add the following line:

    username ALL=(root)NOPASSWD:/usr/sbin/dmidecode2

    Where username is a user name of the dedicated audit account.

    This allows the dedicated audit account to run the /usr/sbin/dmidecode2 command as root using the sudo command on any host without being asked for the password.

  5. Rename the original dmidecode file to dmidecode2:

    mv /usr/sbin/dmidecode /usr/sbin/dmidecode2

  6. Run the following commands to create a new script file named od:

    echo '#!/bin/bash' > /usr/sbin/dmidecode
    echo '/usr/sbin/sudo /usr/sbin/dmidecode2 "$@"' >> /usr/sbin/dmidecode
    chown root:root /usr/sbin/dmidecode
    chmod 755 /usr/sbin/dmidecode

  7. Test that the dmidecode command is now replaced with the dmidecode script. For example, run the following command:

    dmidecode -u

    If the sudoers file is configured correctly, this command will output SMBIOS data.

    To test remote execution, run the following from the machine on which the Automation Server is installed:

    "C:\Program Files\Common Files\Alloy Shared\RemoteAudit\bin\plink.exe"
    -batch -t -l username -pw password 192.168.0.1 "dmidecode -u"

    Where

    • "C:\Program Files\Common Files\Alloy Shared\RemoteAudit\bin\plink.exe" is the path to the plink.exe file,
    • username is the username of the dedicated audit account,
    • password is the password for the dedicated audit account,
    • 192.168.0.1 is the IP address of the audited Linux machine.

    If this command returns SMBIOS data, you will be able to run Direct Network Scan of the computer remotely.

    IMPORTANT: If there are some issues with the dmidecode command in your environment, preventing the Direct Network Scan from locating or using this command, it will attempt to access the BIOS storage using the od command. Using od is not recommended due to its limitations with memory access, and can serve only as a last resort. The od command requires the same privileges as dmidecode.