We have looked at quite a lot of fairly custom and customizable ways to get data into Zabbix. Although external checks should allow us to grab data by any means whatsoever, in some cases we might need to collect data from some system that is reachable over SSH or even Telnet, but there is no way to install an agent on it. In that case, a more efficient way to retrieve the values would be to use the built-in SSH or Telnet support.
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 is 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
With the user account in place, let's create the SSH item. In the frontend, go to Configuration | Hosts, click on Items next to A test host, and click on Create item. Fill in the following:
Users logged in (SSH)
ssh.run[system.users]
zabbixtest
(or whatever was the username for your test account)who | wc -l
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 parameter 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.
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 dropdown 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 is not 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 for the Zabbix user.
Encrypted or passphrase-protected keys are not supported by default on several distributions, including Debian. Dependency libssh2
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.
In case of a device that can have neither the Zabbix agent installed, nor supports SSH, Zabbix also has a built-in method to obtain values over Telnet. With Telnet being a really old and insecure protocol, that is probably one of the least suggested methods for data gathering.
Telnet items are similar to SSH items. The simplest item key syntax is the following:
telnet.run[<unique_identifier>]
The key itself is a fixed string, while the first parameter is a unique identifier, the same as for the SSH items. Also the second and third parameter are IP address and port, if they are different from the host interface IP and the default Telnet port, 23. The commands to run will go in the Executed script field, and the username and password should be supplied as well.
For the login prompt, Zabbix looks for a string that ends with :
(colon). For the command prompt, the following are supported:
$
#
>
%
When the command returns, at the beginning of the string, up to one of these symbols is trimmed.