Probleme mit ssh nach Wechsel auf Versin 2.0.0p1

Mit den Wechsel von 1.6.0p22 auf 2.0.0p1 funktioniert die Abfrage des Agenten über ssh nicht mehr.

Das Problem liegt an einen Versionskonflikt der libssl.so.1.1 und libcrypto.so.1.1 aus dem Betriebssystem (SLES 15 Sp2) und den im cmk enthaltenen Bibliotheken. Als Workaround wurden die Bibliotheken aus /usr/lib/ nach /omd/sites//lib/ kopiert; eine Anpassung der ~/etc/enviroment hatte noch mehr Probleme bereitet.
Die Abfrage über ssh funktioniert dadurch wieder, jedoch laufen dann die http(s) checks in einen Fehler.

Übersehe ich dabei noch etwas oder muss ich auf das nächste Bugfix zu warten?

Was genau kommt den als Fehler? Vom ssh wie von den https Checks.

Hallo,
innerhalb von WATO kommt die Meldung:
[agent] Program ‘ssh’ not found (exit code 127), Got no information from host, execution time 0.1 sec

auf der Kommandozeile als Site Benutzer:
ssh: symbol EVP_KDF_CTX_free, version OPENSSL_1_1_1d not defined in file libcrypto.so.1.1 with link time reference

als root geht es, ist aber nicht Sinn der Sache.

Hallo @zucki,

wir haben dafür ein internes Ticket und werden es zeitnah fixen.

Gruß
Anastasios

2 Likes

Man kann speziell für ssh die libcrypto des Betriebsystems über LD_PRELIAD verwenden. Command line to execute ist dann: LD_PRELOAD=/usr/lib64/libcrypto.so.1.1 ssh...

1 Like

Hallo,

das Problem besteht nur mit SLES 15 Sp2 - wir haben es hier damit gelöst, dass ich auf Ubuntu 20.ß4 gewechselt bin.
Beide Distributionen sind bei uns im Einsatz und der Umzug mit

omd backup / omd restore

war problemlos,

Den Vorschlag mit LD_PRELIAD werde ich auch versuchen; das könnte in anderen Bereichen auch hilfreich sein.

Danke und Grüße
Zucki

2 Likes

Hallo,
das Thema hatte ich vor einiger Zeit auch, das liegt an der Version von OpenSSL und genauer gesagt an dem “d” oder “k” - Release davon. Das Gleiche kann wieder passieren, wenn die OpenSSL - Version 3 in Einsatz kommt.

Daher habe ich das eleganter gelöst und gehe hier über die CONFIG von SSH und einem eigenem Benutzer auf dem jeweiligen Rechner, der nur das Monitoring ausüben kann. Damit übergibst Du Deinem System die Steuerung davon & das klappt einwandfrei, selbst mit OpenSSL 3.x :wink: :upside_down_face: :upside_down_face:

Herzliche Grüße

Matthias

Hallo,

ich würde gerne das Thema wieder aufrollen. Wir haben das gleiche Problem mit 2.0.0p15 nach einem OS-Update von SLES 15 SP1 auf SP3. Den Vorschlag mit dem LD_PRELOAD=/usr/lib64/libcrypto.so.1.1 habe ich ausprobiert. Ein ssh würde dann auch wieder fukntionieren. Allerdings wirft mir dann schon ein “omd status” folgende Meldung um die Ohren:

OMD[RZ]:~$ omd status
Traceback (most recent call last):
File “/omd/sites/RZ/bin/omd”, line 57, in
import omdlib.main
File “/omd/versions/2.0.0p15.cme/lib/python3/omdlib/main.py”, line 58, in
import omdlib.certs
File “/omd/versions/2.0.0p15.cme/lib/python3/omdlib/certs.py”, line 32, in
from OpenSSL import crypto # type: ignore[import]
File “/omd/versions/2.0.0p15.cme/lib/python3/OpenSSL/init.py”, line 8, in
from OpenSSL import crypto, SSL
File “/omd/versions/2.0.0p15.cme/lib/python3/OpenSSL/crypto.py”, line 15, in
from OpenSSL._util import (
File “/omd/versions/2.0.0p15.cme/lib/python3/OpenSSL/_util.py”, line 6, in
from cryptography.hazmat.bindings.openssl.binding import Binding
File “/omd/versions/2.0.0p15.cme/lib/python3/cryptography/hazmat/bindings/openssl/binding.py”, line 14, in
from cryptography.hazmat.bindings._openssl import ffi, lib
ImportError: /omd/versions/2.0.0p15.cme/lib/libssl.so.1.1: undefined symbol: EVP_idea_cbc, version OPENSSL_1_1_0

Hat hier vielleicht jemand aktuelle Erfahrungen damit gemacht und evtl. eine Lösung oder einen Workaround?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.