Incorrect SSH Protocol Configuration for Linux and Mac
The Direct Network Scan of Linux and Mac computers,
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.
Before starting the Direct Network Scan,
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:
- In the
Alloy Discovery, in the All Nodes grid, locate the problematic computer and double-click this record. The Audit Properties [Node Name] dialog box opens.
- Review the OS Type field value. If you need to correct it, select a value from the drop-down list.
- Click OK.
- Audit the computer again.
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 nardware 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.
setuid bit on the
- Log in to the client Linux machine.
- Open a console dialog box.
- Find the
dmidecodefile (typically, it is in the
- Get root privileges. For example:
- Make sure the
dmidecodefile is owned by
ls -l /usr/sbin/
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/
If it is not, set the ownership to root:root:
chown root:root /usr/sbin/
- Set the
setuidbit for the
chmod 4755 /usr/sbin/
After doing this, any users or processes running the
dmidecodefile will have permissions of its owner, within the executed process. Since the owner is set to root,
dmidecodewill run with root privileges.
- Test that the
dmidecodecommand runs as root under a non-root user account. For example, by running the following:
dmidecoderuns as root, this command will return SMBIOS data.
setuidbit is disabled on many Linux implementations due to security reasons. If
dmidecodedoes not run as root with the
setuidbit set, chances are that your Linux distribution has
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.
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:
- Log in to your Linux machine and open a console dialog box.
- Get root privileges. For example,
- Find the location of your
dmidecodefiles. Typically, they are both in the
- Add the user account that you intend to use as a dedicated audit account to the
sudoerslist on the client Linux machine. To do so, edit the
/etc/sudoersfile and add the following line:
usernameis a user name of the dedicated audit account.
This allows the dedicated audit account to run the
/usr/sbin/dmidecode2command as root using the
sudocommand on any host without being asked for the password.
- Rename the original
- Run the following commands to create a new script file named
echo '#!/bin/bash' > /usr/sbin/
echo '/usr/sbin/sudo /usr/sbin/
dmidecode2 "$@"' >> /usr/sbin/
chown root:root /usr/sbin/
chmod 755 /usr/sbin/
- Test that the
dmidecodecommand is now replaced with the
dmidecodescript. For example, run the following command:
sudoersfile is configured correctly, this command will output SMBIOS data.
To test remote execution, run the following from the machine on which the
InventoryServer 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"
"C:\Program Files\Common Files\Alloy Shared\RemoteAudit\bin\plink.exe"is the path to the
usernameis the username of the dedicated audit account,
passwordis the password for the dedicated audit account,
192.168.0.1is 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
odis not recommended due to its limitations with memory access, and can serve only as a last resort. The
odcommand requires the same privileges as dmidecode.