SSH items

Let's look at the SSH items first. As a simple test, we could re-implement the same Zabbix agent parameter we did as our first user parameter, determining the number of the currently logged-in users by running who | wc -l. To try this out, we need a user account we could use to run that command, and it's probably best to create a separate account on A test host. Creating one could be as simple as the following:

# useradd -m -s /bin/bash zabbixtest
# passwd zabbixtest 

Don't create unauthorized user accounts in production systems. For remote systems, verify that the user is allowed to log in from the Zabbix server.

With the user account in place, let's create the SSH item. In the frontend, follow these steps:

1. Go to Configuration | Hosts, click on Items next to A test host, and click on Create item. Fill in the following:

• • Name: Users logged in (SSH)
  • Type: SSH agent
  • Key: ssh.run[system.users]
  • User name: zabbixtest (or whatever was the username for your test account)
  • Password: Fill in the password used for that account
  • Executed script: who | wc -l

The fields are shown in the following screenshot:

The username and password will be kept in plain text in the Zabbix database.

2. When done, click on the Add button at the bottom.

For the key, we could customize the IP address and port as the second and third parameters respectively. Omitting them uses the default port of 22 and the host interface address. The first parameter for the item key is just a unique identifier. For SSH items, the key itself must be ssh.run, but the first parameter works in a similar fashion to the whole key for user parameters. In the Latest data page, our first SSH item should be working just fine and returning values as expected. This way, we could run any command and grab the return value.

In most cases, it's suggested to use user parameters instead of SSH checks' we should resort to direct SSH checks only when it's not possible to install the Zabbix agent on the monitored system.

The item we just created uses a directly supplied password. We could also use key-based authentication. To do so, in the item properties, choose Public key for the Authentication method drop-down menu and fill in the name of the file that holds the private key in the Private key file field. Although the underlying library allows skipping the public key when compiled with OpenSSL, Zabbix currently requires specifying the public key filename in the Public key file field. If the key is passphrase-protected, the passphrase should be supplied in the Key passphrase field. But where should that file be located? Check the Zabbix server configuration file and look for the SSHKeyLocation parameter. It isn't set by default, so set it to some directory and place the private and public key files there. Make sure the directory and all key files are only accessible by the Zabbix user.

Encrypted or passphrase-protected keys aren't supported by default in several distributions, including Debian. The libssh2 dependency might have to be compiled with OpenSSL to allow encrypted keys. See https://www.zabbix.com/documentation/3.0/manual/installation/known_issues#ssh_checks for more detail.