feed-image -=Kernel-Error=- BlogFeed

RSPAMD automatisch SPAM / HAM lernen mit Dovecot und IMAPSieve

Bei jedem Spamfilter rutscht schon mal spam durch oder eine echte Nachricht wird falsch als spam eingestuft. Rspamd bietet über das Webinterface die Möglichkeit trainiert zu werden. Hier kann man einfach den Quellcode jeder E-Mail kopieren und rspamd die Information mitgeben ob es sich dabei um SPAM oder HAM handelt. Dieses Vorgehen ist vollständig unbrauchbar um den Spamfilter ordentlich zu trainieren.

Viel schöner wäre doch Folgendes: Immer wenn ein Benutzer eine E-Mail in den Ordner "Junk" schiebt soll diese E-Mail automatisch von rspamd als Spammail gelernt werden. Zusätzlich soll jede E-Mail welche vom Benutzer aus dem "Junk" Ordner herausgeholt wird als Ham gelernt werden.

Genau dieses Beispiel möchte ich hier kurz beschreiben. Hostsystem ist dabei ein FreeBSD, Linuxuser müssen daher bei den Ordnern /usr/local etwas aufpassen! Ebenfalls lauscht mein rspamd-worker nicht auf einen unix-socket sondern auf der IP 127.0.0.3, da er in einer jail steckt.

 

 Beginnen wir mit der Konfiguration für dovecot.

20-imap.conf:

protocol imap {
  mail_plugins = $mail_plugins imap_sieve
}

90-plugin.conf:

plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms

  # From elsewhere to Spam folder or flag changed in Spam folder
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox1_causes = COPY FLAG
  imapsieve_mailbox1_before = file:/usr/local/etc/dovecot/sieve/report-spam.sieve

  # From Spam folder to elsewhere
  imapsieve_mailbox2_name = *
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_before = file:/usr/local/etc/dovecot/sieve/report-ham.sieve

  sieve_pipe_bin_dir = /usr/local/libexec/dovecot

  sieve_global_extensions = +vnd.dovecot.pipe
}

/usr/local/etc/dovecot/sieve/report-spam.sieve:

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "imap4flags"];

if environment :is "imap.cause" "COPY" {
    pipe :copy "sa-learn-spam.sh";
}

# Catch replied or forwarded spam
elsif anyof (allof (hasflag "\\Answered",
                    environment :contains "imap.changedflags" "\\Answered"),
             allof (hasflag "$Forwarded",
                    environment :contains "imap.changedflags" "$Forwarded")) {
    pipe :copy "sa-learn-spam.sh";
}

/usr/local/etc/dovecot/sieve/report-ham.sieve:

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.mailbox" "*" {
  set "mailbox" "${1}";
}

if string "${mailbox}" [ "Trash", "train_ham", "train_prob", "train_spam" ] {
  stop;
}

pipe :copy "sa-learn-ham.sh";

Natürlich nicht vergessen die beiden neuen Sieve scripte für sieve zu compilieren:

# sievec /usr/local/etc/dovecot/sieve/report-spam.sieve
# sievec /usr/local/etc/dovecot/sieve/report-ham.sieve

Fehlen nur noch die beiden shell scripte um die Mails an rspamd weiterleiten zu können.

/usr/local/libexec/dovecot/sa-learn-spam.sh:

#!/bin/sh
exec /usr/local/bin/rspamc -h 127.0.0.3:11334 learn_spam

/usr/local/libexec/dovecot/sa-learn-ham.sh:

#!/bin/sh
exec /usr/local/bin/rspamc -h 127.0.0.3:11334 learn_ham

Beide müssen ausführbar sein:

# chmod +x /usr/local/libexec/dovecot/sa-learn-spam.sh /usr/local/libexec/dovecot/sa-learn-ham.sh

So wenn ich nun eine E-Mail in den Ordner "Junk" verschiebe lernt rspamd diese automatisch als Spam:

2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_controller_check_password: allow unauthorized connection from a trusted IP 127.0.0.3
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_message_parse: loaded message; id: <FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net>; queue-id: <undef>; size: 49053; checksum: <f5e2fc59515e1da33d532c6f03f6f6f0>
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_controller_learn_fin_task: <127.0.0.3> learned message as spam: FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net

Verschiebe ich eine E-Mail aus dem Ordner "Junk" heraus wird sie, wie gewünscht, als Ham gelernt:

2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_controller_check_password: allow unauthorized connection from a trusted IP 127.0.0.3
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_message_parse: loaded message; id: <FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net>; queue-id: <undef>; size: 49053; checksum: <f5e2fc59515e1da33d532c6f03f6f6f0>
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_controller_learn_fin_task: <127.0.0.3> learned message as ham: FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net

Tjo... Fragen? Dann fragen..

Oh was man nicht mehr verwenden sollte ich etwas wie das antispam plugin das ist "tot".

AliExpress Labornetzteil - RIDEN RD6006 DC POWER SUPPLY

Vor knapp 20 Jahren habe ich mir ein Labornetzteil gebaut. Elektronik lernen und verstehen war dabei das Ziel. Das Netzteil liefert mir 30V und 3A ist Kurzschlusssicher und hält Strom und Spannung auch unter Last sauber. Es ist komplett analog mit zwei dreistelligen Segmentanzeigen für Strom und Spannung.
Insg. ein sehr schönes Gerät welches mich schon viele Jahre begleitet. Dennoch stößt es immer wieder an seine Grenzen. Ich möchte mehr als 30V oder benötige mehr als 3A. Zum einfachen Messen muss ich weitere Geräte einschleifen, ebenfalls wenn ich Strom/Spannung sehr fein einstellen möchte geht es nicht ohne weiteres Messgerät und etwas Fingerspitzengefühl.
VerlaufskurvRIDEN RD6006 DC POWER SUPPLY Labornetzteilen digital speichern, vorgespeicherte Werte schnell abrufen und ausgeben oder einfach zwischen verschiedenen Werten schnell wechseln…. Alles Dinge an welche man bei dem Gerät nicht denken muss. Ebenfalls ist es kein modernes Schaltnetzteil, sondern basiert noch „ganz Oldschool“ auf einem großen Trafo. Erst dahinter mache ich Strom und Spannung „sauber“ zu den damit verbundenen Nachteilen kommt die hohe Verlustleistung in Wärme.
Ein neues Labornetzteil was mir diese Möglichkeiten eröffnet muss her. Dabei benötige ich kein Highendgerät. Dafür sind meine Anwendungen zu simpel. Preis/Leistung muss halt passen. Ich bin daher auf das RIDEN RD6006 gestoßen. Ein Gerät von AliExpress aus China… Puhhh… Naja, im Grunde kommt ja inzwischen fast alles aus China. Nur kommt ebenfalls viel Schrott von dort. Die Eckdaten des Netzteils sind so gut, dass ich es probieren wollte.

Nach knapp 3 Wochen waren alle Teile bei mir und ich konnte beginnen es zusammen zu bauen. Das Handbuch gibt es als PDF in Chinesisch und Englisch, in diesem ist das nötigste beschrieben. Ich kann Akkus damit Laden, bekomme bei 60V noch 6A heraus, es lässt sich per USB mit dem PC verbinden, es gibt Software dafür, Firmwareupdates ebenfalls und und und…

Gut, das WLAN Modul funktioniert irgendwie nicht oder öhm nicht so wie ich es erwarten würde. Der Temperatursensor zur Überwachung der Akkutemperatur beim Laden muss „irgendwie“ aus dem Gehäuse gelegt werden und ich habe mich dann die Schutzerde doch zusätzlich noch ans Gehäuse geklemmt.

Davon abgesehen ist das Ding echt gut. Ja es tut was es soll und steigert meine Möglichkeiten.

Hier der Link zum "Nachkaufen":  https://de.aliexpress.com/item/4000282551930.html

  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-001
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-002
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-003
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-004
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-005
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-006
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-007
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-008
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-009
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-010
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-011
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-012
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-013
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-014
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-015
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-016
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-017
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-018
  • RD6006-RIDEN-DC-PowerSupply-Labornetzteil-019

TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384 was bedeutet das eigentlich? TLS cipher einfach erklärt..

TLS_AES_256_CGM_SHA384 oder TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384 liest man immer mal wieder, wenn man sich etwas mit Transportverschlüsselung beschäftigt. Was genau dieses bedeutet ist nicht immer ganz klar. Daher möchte ich einmal probieren es etwas aufzuschlüsseln.

Um dieses nachvollziehen zu können, müssen vorher noch die folgenden Begriffe geklärt werden:

  • Key exchange
    Damit ist der Schlüsselaustausch gemeint.
  • Certificate verification
    Hier geht es um das eigentliche Zertifikat vom Server.
  • Bulk encryption
    Die eigentliche Verschlüsselung welche am Ende genutzt wird um die Daten auf ihrem Weg zu verschlüsseln.
  • Hashing
    Die eingesetzten Prüfsummen um sicherstellen zu können, das alles „richtig“ ist.

 Verschlüsselung-cipher

Ebenfalls muss man wissen, dass es seit TLSv1.3 einen Unterschied in der Schreibweise der cipher suite gibt. Bei <= TLSv1.2 tauchen in der cipher suite als erstes das Protokoll auf, dann der Algorithmus für den Schlüsselaustausch, nun die digitalen Signaturen des Serverzertifikates gefolgt vom „Rest“. Die Menge möglicher Kombinationen ist jetzt schon sehr hoch. Damit diese „Liste“ nicht in ihrer Länge explodiert hat man bei TLSv1.3 die beiden Punkte Key exchange und Certificate verification aus der Schreibweise entfernt.

 

Mit diesem Wissen kann man nun anfangen die beiden Zeichenkennten zu „zerlegen“.

 

TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384

  • TLS
    Nicht schwer, das eingesetzte Protokoll TLS (Transport Layer Security)
  • ECDHE
    Key exchange in diesem Fall ECDHE
  • ECDHE
    Certificate verification bei mir inzwischen ECDHE, sehr oft aber RSA
  • WITH_AES_256_GCM
    Bulk encryption also die eigentliche Verschlüsselung der Daten. In diesem Fall AES (Advanced Encryption Standard) mit der maximalen Länger von 256bit und GCM (Galois/Counter Mode).
  • SHA384
    Das eingesetzte Hashing SHA (Secure Hash Algorithm) in Version 2 mit einer Länge von 384bit.

TLS_AES_256_CGM_SHA384 schafft nun jeder allein, oder?

Sprechen wir noch kurz über den Key exchange. In diesem ist spezifiziert, wie sich Client und Server auf einen eigenen Schlüssel für ihre verschlüsselte Kommunikation einigen. Brauchbar sind dabei Kombinationen aus DHE (wenn sie >= 2048bit sind) und besser noch ECDHE, dabei stehe EC für elliptische Kurven DHE ist Diffie-Hellman. Diffie-Hellmann hat nämlich eine Möglichkeit aufgeführt, wie man für die Verschlüsselung einer Verbindung temporäre Schlüssel einsetzten kann. Denn es lassen sich auch verschlüsselte Verbindungen aufzeichnen. Natürlich kann man so noch immer nicht den Inhalt sehen.. Kommt man an den eingesetzten Schlüssel für die Kommunikation kann man diese damit entschlüsseln. Setzte man also auf einen temporären Schlüssel, gibt es diesen nur für eine gewisse Zeit und dann verschwindet er. Die Zeit, um an diesen Schlüssel zu kommen, ist daher extrem begrenzt und sorgt für eine zusätzliche Sicherheit. „Früher“ hat es gereicht sich einfach irgendwann/irgendwie den Schlüssel vom Server zu besorgen und man konnte mit diesem die Aufgezeichneten Verbindungen entschlüsseln. Bugs wie Heartbleed haben dieses noch vereinfacht. DHE minimiert also etwas das Risiko von Bugs und ergaunerten privat Keys vom Server. Man möchte für seine Verbindungen also nur DHE, besser noch ECDHE! Am besten bietet der Server nichts anders an, da sonst ggf. ein Angreifer versuchen könnte die Verbindung auf etwas „schlechteres“ herunter zu stufen, um so doch am Ende wieder an etwas kommen zu können.

Wenn wir dabei sind… Certificate verification. Nur eine verschlüsselte Verbindung alleine hilft ja nicht, wenn man sich mit dem falschen Server unterhält. Ich meine damit, dass ein Angreifer einfach dafür sorgt, dass wir nicht mit dem gewünschten Server sprechen, sondern mit seinem und dieser vielleicht einfach nur alle Daten durchreicht. Um dieses möglichst zu erschweren gibt es eine ganze Reihe verschiedener Möglichkeiten. Eine davon ist die Certificate verification. Der Server hat also ein Zertifikat, welches vielleicht noch von einer CA signiert wurde, dessen Prüfsumme im DNSsec geschützten DNS liegt, zu dem es HPKP (http Public Key Pinning) gibt oder oder… Dieses Zertifikat sollte daher ebenfalls so gebaut sein, dass man es nicht einfach „nachmachen“ kann. Daher sollte es >=2048bit RSA (asymmetrisches kryptographisches Verfahen) sein, besser noch 4096bit RSA. Hier sieht man schon ein „Problem“. Die Systeme „rechnen“ schneller und damit wird die Bitzahl erhört und die zu übertragenden Daten und das errechnen der Clients usw.. Insg. keine sehr schöne Lösung. ECDHE Zertifikate sind deutlich kleiner, damit schneller zu übertragen und zudem noch für den Client schneller zu prüfen.

Als Beispiel:
Ein Zertifikat mit elliptischen Kurven und einer Länge von 256bit ist grob vergleichbar mit einem RSA Zertifikat mit 3072bit. Wenn jemand daher auf elliptische Kurven setzt, sollten diese nicht kleiner als <=secp256r1 sein. secp224r1 liegt schon zu nahe an 1024bit RSA und fliegt bald weg. secp384r1 ist ganz vorne mit dabei, hat aktuell keinen besonderen Vorteil.

Bulk encryption, tjo die eingesetzte Verschlüsselung. Hier gibt es verschiedene Kombinationen, welche als „sicher“ gelten. Alle zu erklären sprengt sicher den Rahmen. April 2020 kann man sicher merken:

Kombinationen aus AES >=128bit mit GCM oder ChaCha20 mit Poly1305 sind ganz gut. OK ist im Moment noch AES >=128bit mit CBC. 3DES sollte man in keiner Kombination mehr nutzen, das fliegt bald aus der „Sicher“ Liste raus, so wie <= TLSv1.2. Von allen anderen Kombinationen sollte man tunlichst die Finger lassen!

Das Hashing bei der Bulk encryption (das Hashing für Key exchange und Certificate verification hängt am Serverzertifikat, unterliegt den gleichen Merkpunkten) sollte etwas um >= 256bit SHA 2 sein. Ein ganz guter Mittelweg ist hier SHA-384. SHA1 „geht“ wohl dabei ebenfalls noch. Ich würde davon und von allem anderen dennoch die Finger lassen. Wenn ihr irgendwo MD5 RC4 oder ähnliches seht, rennt weg!

Habe ich etwas vergesse, ist etwas falsch oder es gibt Fragen? Dann einfach E-Mail bitte!

Was habe ich da wieder gekauft?!? OBI LED

Vor knapp zwei Jahren habe ich für meine Werkstatt ein paar neue Deckenleuchten benötigt. Bisher waren zwei Neonröhren meine Lichtquelle. Lichtfarbe und Stärke passten einfach nicht mehr. Im OBI habe ich zu diesem Zeitpunkt zufällig LED Leuchten gesehen, welche in Form und Länge an klassische Neonröhren erinnern. Der Preis lag irgendwo zwischen 10 bis 20 €, also kein Preis bei dem man viel falsch machen kann, oder?

Naja, vielleicht ja doch!??! Jetzt nach zwei Jahren beginnen ein paar der LED Leuchten zu flackern. Also schnell eine der Leuchten von der Decke geschraubt um sie zu zerlegen. Vielleicht findet sich ja das Problem?!?
OBI LED SCHROTT Typ LY-5024-2 von Ritter Leuchten GmbH
Die Schaltung ist sehr überschaubar. Zuerst eine kleine Sicherung, dann ein Brückengleichrichter, ein kleiner Kondensator zur Spannungsglättung (ich habe wohl zwei Versionen der Leuchten, mit und ohne diesen Kondensator), ein kleiner hochohmiger Widerstand (zur schnellen Entladung vom Kondensator beim „Licht aus“) und noch zwei „Einchip“ LED Treiber mit seinen Steuerwiderständen. Oh und natürlich die einzelnen LEDs!

Der Brückengleichrichter ist ein MB6s, welcher laut den Specs „passen“ sollte. Der 400v 10uF Kondensator zur Spannungsglättung passt ebenfalls für mich, auch der 1M Ω Endladewiderstand passt schon. AAAABBBEERRR die beiden LED Treiber SM2082D sehen schon etwas spannend aus, so als wenn die „warm“ werden. Laut specs geben sie bei 10V bis zu 60mA raus. Der Rest wird also in „Wärme“ verwandelt. Was man an den Operating temperature von -40 ~ 125°C bewundern kann.

Bei den Leuchten mit Kondensator pendelt sich die Temperatur bei etwas zwischen 70 und 75°C ein. Bei den Leuchten ohne Kondensator werden es auch mal 90°C. Da hat der kleine LED Treiber wohl ganz schön was zu regeln, wohl der Grund warum in Version 2 ein Kondensator vorgesehen ist ;-)

Gut der Hersteller hat versucht mit etwas Wärmeleitpaste auf der Rückseite des LED Streifens die Temperatur ans Alugehäuse abzugeben. Die Menge und Verteilung der Wärmeleitpaste ist aber sehr sehr dürftig. Nach etwas Einsatzzeit nimmt die Leistung der Paste natürlich ab und irgendwann ist es halt zu schlecht oder besser gesagt, die LED Treiber werden zu heiß und verbrennen ihre eigenen Lötkontakte bis zum Haarriss. Dann flackert es... Ich habe daher die Kontakte nachgelötet (kein Flackern mehr) und mit Wärmeleitkleber einen kleinen Kühlkörper auf die Treiber geklebt. Damit hält sich die Temperatur bei knapp 50°C. Das sollte die Lebenszeit deutlich erweitern. Passende Kondensatoren liegen hier ebenfalls noch und sind verbaut. Mal sehen wie lange sie nun nicht flackern!

Zusätzlich habe ich das Alugehäuse noch mit der Schutzerde verbunden. Die simple Lackisolierung vom LED Streifen bei den Temperaturen hat mich nicht ganz überzeugt ;-)

Ich würde sagen, dass hat jemand auf Verschleiß gebaut. Die Leuchten sollen wohl kurz nach der Garantie ausfallen. So zumindest mein Eindruck.... Bei dem Preis, naja...

  • Ritter-Leuchten-LY-5024-2-Obi-LED-Leuchte-01
  • Ritter-Leuchten-LY-5024-2-Obi-LED-Leuchte-02
  • Ritter-Leuchten-LY-5024-2-Obi-LED-Leuchte-03
  • Ritter-Leuchten-LY-5024-2-Obi-LED-Leuchte-04
  • Ritter-Leuchten-LY-5024-2-Obi-LED-Leuchte-05
  • Ritter-Leuchten-LY-5024-2-Obi-LED-Leuchte-06
  • Ritter-Leuchten-LY-5024-2-Obi-LED-Leuchte-07

 

Natürlich hätte ich damit rechnen können. Ich meine Leuchten kaufen, im OBI und dann für etwas bis 20€. Was können die schon in der Herstellung gekostet haben?

Typ LY-5024-2 von Ritter Leuchten GmbH www.ritos.de

SSH bruteforce mit "alter" Implementierung?!?

Wenn man mit einem System im Internet steht fummelt immer irgendein script kiddie oder bot an den Diensten herum. Oft ist hier eine IP Adresse aus China dabei. Dann probieren sie ein paar default logins und wandern weiter zur nächsten IP Adresse. Die Bots geben dem Ganzen in der Regel schon nicht mehr als drei Versuche, weil sie dann eh von irgendeinem Sicherheitssystem geblockt werden. Da es noch viele andere bots hinter anderen IP Adressen gibt, übermittelt der bot nur seinen Stand der Versuche an das Hirn des Botnetzes und der nächste, nicht geblockte bot, kommt und probiert es weiter...

Alles "kalter Kaffee"... In den letzten Wochen fallen mir zwei kleine Veränderungen auf.

old SSH Bot

Einmal kommen diese IP Adressen noch immer stark aus China... ABER sehr oft ebenfalls von DigitalOcean (USA). Zudem fallen mir die anderen Cloudprovider auf (Google, Microsoft, AWS...). Das verschiebt sich aktuell wohl etwas. Normalerweise kommt ganz viel aus China, dann ganz viel von verschiedenen dynamischen Endkundenanschlüssen auf der Erde. Jetzt kommt ganz viel aus China, dann unglaublich nahe daran Digitalocean, direkt gefolgt von der google-cloud und microsoft-cloud. Erst jetzt kommen die Endkundenanschlüsse und mischen sich mit Adressen aus der AWS-Cloud. Scheinbar haben die Amazonjungs irgendetwas "besser" gemacht, um ihre Kunden davor zu schützen sich etwas "einzufangen"?!?

Zweitens scheint da ein Botnetz mit recht alter ssh Implementierung unterwegs zu sein. Oder es sucht halt speziell alte SSH-Server? Auf IoT Geräte mit alter Firmware tippe ich weniger, denn von diesen kommt ebenfalls etwas von Cloudanbietern. Bei denen unterstelle ich einfach mal, keine alten IoT Geräte im Einsatz zu haben, die infiziert sind. Naja... Oder es wird halt nach genau solchen Geräten gesucht. Warum alt? Weil ich so etwas in den Logs finde:

Apr  8 10:35:58 YOURMOM sshd[43201]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:35:58 YOURMOM sshd[43201]: Did not receive identification string from 1.2.3.4 port 34244
Apr  8 10:36:22 YOURMOM sshd[43202]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:36:22 YOURMOM sshd[43202]: Unable to negotiate with 1.2.3.4 port 36160: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
Apr  8 10:36:42 YOURMOM sshd[43204]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:36:42 YOURMOM sshd[43204]: Unable to negotiate with 1.2.3.4 port 39556: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

Wie ist das bei euch?