Registration of a client against SUSE Manager Server fails with "not supported between instances of 'dict' and 'int'"

This document (000021349) is provided subject to the disclaimer at the end of this document.


SUSE Manager 4.3 Server


Red Hat Enterprise Linux (RHEL) client using the "Push via SSH" contact method was registered against the SUSE Manager Server, however, running salt states after initial registration failed with following error message:
  File "/usr/lib/python3.6/site-packages/jinja2/", line 37, in reraise
    raise value.with_traceback(tb)
  File "<template>", line 15, in top-level template code
TypeError: '<' not supported between instances of 'dict' and 'int'
When salt states (highstate) were re-triggered manually they finished correctly. In this particular case this was not an option as clients were registered via automation and when the initial salt states failed, clients were not setup correctly after registration.


Check all network components between the SUSE Manager Server and clients for any enabled protection against flood of ssh connections and disable it (when a security policy allows that).


A firewall between the SUSE Manager Server and clients which denied flood of ssh connections. Multiple ssh connections are established during the registration (using Push via SSH contact method) and initial setup of the client.

Additional Information

During the registration of clients against SUSE Manager Server using the Push via SSH contact method, multiple ssh connections are established. Following test:
for run in {1..20}; do ssh REMOTE_USER@REMOTE_HOST uname -a; done
showed, that the connection is being RESET after several ssh attempts:
user@some.hostname's password:
Linux some.hostname 4.18.0-425.3.1.el8.x86_64 #1 SMP Fri Sep 30 11:45:06 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux
kex_exchange_identification: read: Connection reset by peer
Connection reset by port 22
kex_exchange_identification: read: Connection reset by peer
Connection reset by port 22
kex_exchange_identification: read: Connection reset by peer
Connection reset by port 22
During such a test tcpdump was captured on both ends (SUSE Manager Server and the client) and this showed that both sides were getting RST(reset) packets, but neither of those sides were sending them. So there had to be a component in the middle which were sending the RST packets. 


This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000021349
  • Creation Date: 06-Feb-2024
  • Modified Date:06-Feb-2024
    • SUSE Manager Server
    • SUSE Manager

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center