ZABBIX BUGS AND ISSUES
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-8138

"net.tcp.service[ssh]" key returns 0 if SSH server configured with a "motd"

    Details

      Description

      If a ssh server responds like this:

      # telnet host.tld 22
      Trying 10.10.10.10...
      Connected to host.tld.
      Escape character is '^]'.
      
      This computer resource is the property of Company. Authorized persons
      may use Company computer resources only for approved purposes. Misuse
      or misappropriation of company networks and systems is prohibited.
      
      Company reserves the right to audit, access and inspect electronic
      communications and data created, stored, or transmitted on its computer
      resources in accordance with applicable law.  Company also reserves
      the right to add necessary files and modify the configuration of any
      connected computer or system to ensure the security and integrity of
      its computer resources.
      
      BY COMPLETING THE LOGIN PROCESS YOU ARE ACKNOWLEDGING AND CONSENTING TO
      THE PROVISIONS OF THIS NOTICE. IF YOU ARE NOT AN
      AUTHORIZED USER, PLEASE DISCONTINUE THE LOGIN PROCESS NOW.
      
      
      SSH-2.0-Sun_SSH_1.0.1
      

      then "net.tcp.service[ssh] key" returns 0 as value, which is wrong.

      In "check_ssh" zabbix function we see that zabbix supposes that response should start from "SSH" character.

      My debian host responds with only one line: "SSH-2.0-OpenSSH_6.6p1 Debian-3" and the key works correctly on it.

        Activity

        Hide
        Oleksiy Zagorskyi added a comment -

        http://tools.ietf.org/html/rfc4253 says:

        The server MAY send other lines of data before sending the version
        string. Each line SHOULD be terminated by a Carriage Return and Line
        Feed. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded
        in ISO-10646 UTF-8 [RFC3629] (language is not specified). Clients
        MUST be able to process such lines. Such lines MAY be silently
        ignored, or MAY be displayed to the client user. If they are
        displayed, control character filtering, as discussed in [SSH-ARCH],
        SHOULD be used. The primary use of this feature is to allow TCP-
        wrappers to display an error message before disconnecting.

        Show
        Oleksiy Zagorskyi added a comment - http://tools.ietf.org/html/rfc4253 says: The server MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a Carriage Return and Line Feed. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC3629] (language is not specified). Clients MUST be able to process such lines. Such lines MAY be silently ignored, or MAY be displayed to the client user. If they are displayed, control character filtering, as discussed in [SSH-ARCH] , SHOULD be used. The primary use of this feature is to allow TCP- wrappers to display an error message before disconnecting.
        Hide
        Juris Miščenko (Inactive) added a comment -

        Fix for 2.2 available at svn://svn.zabbix.com/branches/dev/ZBX-8138

        Show
        Juris Miščenko (Inactive) added a comment - Fix for 2.2 available at svn://svn.zabbix.com/branches/dev/ZBX-8138
        Hide
        Juris Miščenko (Inactive) added a comment -

        Fixed in 2.2.4rc1 r45459, 2.3.0 (trunk) r45465

        Show
        Juris Miščenko (Inactive) added a comment - Fixed in 2.2.4rc1 r45459, 2.3.0 (trunk) r45465
        Hide
        Andrey Mitrofanov added a comment -

        I've updated my server from 2.2.3 to 2.2.5 and got a slight breakage from this ticket changeset. 6 out of 400+ hosts with net.tcp.service.perf[ssh] check showed a PROBLEM. The breakage is attributed to this change as that service on those hosts was up and operational.

        tcpdump of the check sessions shows the difference I think is giving the false positive here. Problem host sends one version line, but it is split thru several packets and 1st one of them do not contain a newline character. My guess is that find_ssh_ident_string() fails on that 1st packet as strchr(l, '\n') does not find the newline and check_ssh() makes no attempt to fetch a full line and fails. At the same time the 2.2.3 version of the check was quite happy with that 1 packet as it contained enough chars for SSH-%d.%d- sscanf pattern.

        Those servers' admins got rid of the trigger by some sshd configuration tweak, but the code is broken it seems. Should there be used a tcp_expect() call or a zbx_tcp_recv_line() from trunk?

        Thanks!

        Show
        Andrey Mitrofanov added a comment - I've updated my server from 2.2.3 to 2.2.5 and got a slight breakage from this ticket changeset. 6 out of 400+ hosts with net.tcp.service.perf [ssh] check showed a PROBLEM. The breakage is attributed to this change as that service on those hosts was up and operational. tcpdump of the check sessions shows the difference I think is giving the false positive here. Problem host sends one version line, but it is split thru several packets and 1st one of them do not contain a newline character. My guess is that find_ssh_ident_string() fails on that 1st packet as strchr(l, '\n') does not find the newline and check_ssh() makes no attempt to fetch a full line and fails. At the same time the 2.2.3 version of the check was quite happy with that 1 packet as it contained enough chars for SSH-%d.%d- sscanf pattern. Those servers' admins got rid of the trigger by some sshd configuration tweak, but the code is broken it seems. Should there be used a tcp_expect() call or a zbx_tcp_recv_line() from trunk? Thanks!
        Hide
        richlv added a comment -

        could you please open a new bugreport ?

        Show
        richlv added a comment - could you please open a new bugreport ?

          People

          • Assignee:
            Unassigned
            Reporter:
            Oleksiy Zagorskyi
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: