Putty, SSH und Server refused our key

Du hast dir die Mühe gemacht, deinen Debian oder Linux-Server mit Pubkey-Zertifikaten abzusichern und nun bekommst du bei einem neuen Server dauernd die Meldung „Server refused our key“, wenn du dich per Putty verbinden willst?

Hast Du eventuell auch Debian 12, bookworm neu installiert?

Was bisher immer tadellos funktionierte, benötigt offensichtlich nun eine extra Zeile in der

/etc/ssh/sshd_config

PubkeyAcceptedAlgorithms +ssh-rsa

starte danach deinen SSH-Server neu mit:

$ sudo systemctl restart sshd

und der Login über deinen Schlüssel sollte wie bisher weiter funktionieren.

Du kannst im Vorfeld auch selbst überprüfen, ob die Einschränkung des Algorithmus die Ursache ist:
Dazu hast du die Möglichkeit, den Loginprozess auf den SSH-Server zu mitzuloggen, bzw. die Ausgaben live abzusehen.

Starte hierzu einen extra SSH-Serverprozess auf der Linux-Shell mit z.B. Port 2020

sudo `which sshd` -p 2020 -Dd

Du bekommst dann schonmal rund 13 Zeilen Debug-Ausgaben mit dem Hinweis, dass der Server nun an Port 2020 lauscht.
Nun kannst du dich vom Client her, z.B. Putty, auf diesen Port verbinden und dabei wie gewohnt deinen Private-Key mit einbinden.

Wenn bei den Debug-Ausgaben auf dem Linux-Rechner dabei folgende Zeile enthalten ist:

debug1: userauth-request for user mustermax service ssh-connection method publickey [preauth]

, dann ist das der definitive Hinweis, dass du die oben erwähnte Zeile (PubkeyAcceptedAlgorithms +ssh-rsa) in die SSH-Config eintragen darfst.


OpenVPN zwischen Teltonika und Sophos

Ein VPN mit Netz-zu-Netz (Site2Site) Kopplung zwischen Teltonika Mobile Routern und Sophos Firewalls funktioniert bestens.

Daher hier die Anleitung:

1. Schritt: VPN in Sophos Firewall erstellen

In einer Sophos (getestet mit einer SG-125) eine SSL Verbindung (Site-to-site VPN) anlegen. Das lokale und das entfernte Netz eingeben. Die Verbindung als „Connection type“ Server konfigurieren. Nun die VPN-Verbindungsdatei herunterladen.

2. Schritt: APC Datei „zerpflücken“

Die eben heruntergeladene VPN-Datei hat die Endung .apc, z.B. vpnserver.company.de.apc

Im nächsten Schritt geht es darum, die verbindungsspezifischen Daten zu extrahieren. Für die Gegenstelle (Teltonika-Router) benötigt man drei Dateien, Passwort und Username.

Am Anfang stehen die drei nötigen Zertifikate (in der Reihenfolge „Client Zertifikat, CA und Private Key), jeweils mit einigen für uns unnötigen Inforamtionen dazwischen. Wichtig sind immer die Werte ab:
—–BEGIN CERTIFICATE—– bis einschließlich —–END CERTIFICATE—– bzw. beim
Private Key ab —–BEGIN PRIVATE KEY—– bis einschließlich —–END PRIVATE KEY—–.
Dann steht am Ende der APC-Datei noch der Username und das Passwort. Beide beginnen mit REF_, beim Username (ist relativ kurz) steht direkt danach „username“, beim Passwort direkt danach „password“ (dieses ist relativ lang).

Die entsprechenden Teile der Zertifikate und des Private-Keys per z.B. Notepad++ auszuschneiden und in eine neue, leere Datei kopieren.
Wichtig ist auch, dass das „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ mit in die neu zu erstellende Datei übernommen wird.

Diese entsprechend abspeichern (die Dateiendung scheint egal zu sein), also z.B. pk.txt, ca.txt und cz.txt und für den nächsten Schritt vorhalten.
Die Stellen, an denen sich Username und Password in der Datei befindet, habe ich oben rot markiert.

3. Schritt: Teltonika Router konfigurieren

Im Mobile-Router nun eine neue VPN-Verbindung entsprechend des unten gegebene Screenshots konfigurieren. Die drei Dateien in die zugehörigen Fehler hochladen.

Sofern keine Fehler unterlaufen sind oder die Komponenten bei Sophos oder Teltonika abgeändert wurden, sollte die VPN-Verbindung schnell zustande kommen und beide Netze jeweils gegenseitig erreichbar sein.

Sophos Rejected: RBL (cbl.abuseat.org)

Sophos Firewalls können zum Zeitpunkt dieses Postings (Oktober 2021) eingehenden E-Mail Verkehr ablehnen.

D.h. im Logfile erscheinen plötzlich viele Einträge, in denen ankommenden E-Mails wegen vermeinlichem Blacklist-Eintrag bei cbl.abuseat.org abgelehnt werden. Die manuelle Überprüfung der angezeigten Einträge ergeben bei allen Blacklist-Anbietern jedoch keine Auffälligkeiten, d.h. die es handelt sich um ein „falsches Ablehnen“ (false positives).

Ohne irgendeine Änderung an der Firewall-Konfiguration tritt dieser Fehler bei Kunden plötzlich am 12.10.21 auf. Die eingesetzten Firewall-Geräte sind zwei Sophos SG-135, als Failover-Cluster betrieben. Die installierte Firmware-Version ist 9.707-5.

Die Angelegenheit beeinträchtigt den Geschäftsbetrieb von Unternehmen massiv.

Der Grund dafür scheint bisher nicht klar, wird unter dem „Aktenzeichen“ NUTM-13047 dort untersucht.

https://community.sophos.com/utm-firewall/f/mail-protection-smtp-pop3-antispam-and-antivirus/128016/rbl-working-too-well

Es scheint, als habe es etwas mit den eingetragenen DNS-Servern zu tun.

Sophos Firewalls können kein DHCPv6-PD

Zugegebenermaßen, es betrifft nicht jeden. Aber es ist totzdem dramatisch, wenn eine sogenannte UTM Enterprise-Firewall eine Technik nicht beherrscht, die selbst eine kleine Fritzbox schon drauf hat. Es handelt sich um DHCPv6 prefix delegation, was die Fähigkeit bezeichnet, IPv6-Netze vom Zugangsrouter an dahinterliegende Router weiterzureichen. Mit Softwarestand 9.510-5 auf Sophos Firewalls ist diese Funktion auch im Jahr 2019 noch nicht vorhanden.

Für alle, die jetzt nur Bahnhof verstanden haben:
Das ist in etwas so, wie wenn man ein Auto kauft und stellt fest, dass es keinen Rückwärtsgang hat. Natürlich hat man im Autohaus nicht danach gefragt – ist doch selbstverständlich, dass Autos Rückwärtsgänge haben.

Am kuriosesten ist an der Angelegenheit jedoch, wie man sich als Firewall-Hersteller eine solche Blöße leisten kann. Es gibt etliche Fälle von Global-Playern, die praktisch von einem Tag auf den anderen von der Bildfläche verschwunden sind, weil sie sich auf ihren Lorbeeren einfach ausgeruht haben. Daher fällt es schwer nachzuvollziehen, wie Sophos derart am Kunden vorbei entwickeln kann. Es gibt im Forum alleine 193 Anfragen für die Funktion. Das seit über 3 Jahren!
Ich habe gelernt, dass ein Kunde, der sich beschwert, für etwa 170 andere Kunden steht, die sich an der selben Sache stören. Das macht etwa 32.000 Kunden. Denn jeder, der dort seinen Willen kund getan hat, hat schon einen weiten Weg hinter sich, mit Recherchieren, mit Ausprobieren, einloggen, Posten, etc., um dann schließlich festzustellen: Das Ding kann DHCPv6-PD tatsächlich nicht. Die ignorieren die Kunden einfach.

Zeit, zu wechseln, wie dieser Beitrag zeigt…

und

wie der Kunde seit 2013 (!) ignoriert wird.

VMs lassen sich plötzlich nicht mehr migrieren

In einem Datacenter mit einem vmware-Cluster, bestehend aus mehreren ESXi Hosts trat die Unannehmlichkeit auf, dass sich einige virtuelle Maschinen unvermittelt nicht mehr migrieren ließen. Die Option zum Auswählen im Kontextmenu ist einfach ausgegraut, deaktiviert, nicht anklickbar. Ein Hinweis darauf, warum die Funktion nicht mehr verfügbar ist, ist nicht erkennbar. Das Hostbetriebsystem ist VMware ESXi, 6.5.0, 6765664, verwaltet von vCenter Server Appliance 6.5.0, 5973321.
Von der Beharrlichkeit, sich nicht zu anderen ESXi-Hosts migrieren zu lassen, sind Linux wie Windows Maschinen betroffen. Der Inhalt der virtuellen Container scheint somit keine Rolle zu spielen. Snapshots sind konsolidiert, bzw. es bestehen keine. Weiterhin sind keine Images in die virtuellen CD-Laufwerke der VM’s gemountet, was sonst unter vmware auch gerne mal zu informationtechnischem Schluckauf führen kann. Migrationen sind weder live, noch im ausgeschalteten Zustand der betroffenen VM’s möglich. Neustart des vCenter, der Hosts, sowie des Storge bringen keine Abhilfe. Die virtuellen Maschinen erscheinen festgenagelt an die Hardware.

Recherchen bringen Folgendes hervor:

https://kb.vmware.com/s/article/2044369

Notiz vom 09.November 2018 seitens vmware: Currently, there is no resolution

Vmware hat offensichtlich keine Ahnung, warum VM’s spontan nicht mehr korrekt in der Datenbank registriert sind, vCenter Server also an digitaler Amnesie leidet. Eine Lösung gibt es nicht, außer der harten OP an der Datenbank, oder der De- und Reregistrierung betroffener VM’s. Ich bevorzuge Letzteres.

Unangenehm an der Angelegenheit ist, dass man sich so nicht mehr auf die HA-Funktionalität verlassen kann. Die man teuer bezahlt hat. Keine Ahnung, wie sich der vmware Cluster verhält, wenn ein vmware Host wegbricht. Außerdem ist die Migration für den Fall eines Stromausfalles nicht mehr gesichert. Im Falle eines Stromausfalles meldet die USV innerhalb des Rechenzentrums, dass die VM’s in ein anderes RZ zu migrieren sind, um den reibungslosen Betrieb sicher zu stellen. Wenn VM’s jedoch an der Hardware „kleben“, crashen sie mit Ablauf der Batterielaufzeit. Wer kommt dann für den Schaden auf?

HFO Telecom bringt Ansage, dass Sprachkanäle begrenzt sind

Seit Anfang Dezember 2018 erhalte ich Beschwerden von Kunden der HFO Telecom, dass sie die Ansage hören, die maximale Anzahl von Sprachkanälen sei erreicht. Weitere Telefonate können dann nicht mehr geführt werden. Dies tritt ein, wenn zwei Leitungen belegt sind, obwohl vertraglich mehr Sprachkanäle ausgehandelt sind.

Nach Aussagen der HFO Hotline vom 10.Dezember ist dieses Verhalten auf einen Fehler zurückzuführen und sollte nun der Vergangenheit angehören.

HFO Telecom Ausfall

Seit mindestens 6 Uhr am 04.12.2018 wird mir von erheblichen Problemen bei der Erreichbarkeit von Anschlüssen berichtet, die beim SIP-Provider HFO Telecom konnektiert sind. Kunden klagen über einseitige Gespräche, abgehackte Anrufe oder auch totale Unerreichbarkeit.

Die Hotline des Anbieters konnte ich um 8 Uhr gar nicht erst erreichen.

Seit 10.21 Uhr ist der Status bei „NGN-Telefonie“ auf „schwerer Ausfall“ geändert.

Trotz Allem finde ich gut, dass der Anbieter Transparenz zeigt und die Vorfälle auf seiner Statusseite zeitnah publiziert.

Seit 13 Uhr entspannt sich die Lage. Die Kunden können wieder telefonieren.

VPN Durchsatz bei AVM’s Fritzbox

Der VPN Durchsatz der Fritzbox hat mich lange interessiert. Eben weil ich Heimzugänge mit Firmen damit gerne vernetzen wollte. Meine Erfahrungen mit dem Durchsatz waren dabei immer wieder ernüchtern. Mit dem Modell 7490 bekam ich immer nur maximal 1,2 Mbyte/s (entsprechend etwa 10MBit/s) durch die Leitung, egal ob eine weitere Fritzbox oder z.B. eine pfsense oder Linux im Rechenzentrum als Gegenstelle fungierte.

Gut, man kann einwenden, dass die Fritzbox ein Konsumer-Produkt und keine Enterprise Firewall ist. Und man darf sich darüber bewusst sein, dass nur wenige Kunden die Firewall-Funktionalität nutzen, gemessen an den gesamten Verkaufszahlen. Trotzdem dürften es sicher bestimmt einige zehn- bis hunderttausende Nutzer sein.

Recherchen zum VPN-Durchsatz blieben regelmäßig unklar. AVM vermied es, sich in irgendeiner Weise zum Durchsatz zu äußern. Tausend Meinungen in Foren, wenig kontextuelles Verständnis [1], schon gar keine brauchbaren Fakten.
Ein Datendurchsatz wie zu Modemzeiten, schrieb ein Forenteilnehmer jedoch passend im Jahr 2016.

Ebenfalls im Jahr 2016 misst ein Johannes Weber unter https://blog.webernetz.net/fritzbox-vpn-speedtests/ den Durchsatz unter professionelleren Bedingungen, und bestätigt, was ich auch immer messe: Der Durchsatz liegt üblicherweise bei höchstens um die 9 MBit/s. Unterirdisch.

Unter diesem Link schiebt der Hersteller AVM den Durchsatz sogar auf das Verhältnis von Overhead zu Payload, d.h. den Verwaltungsdaten zu Nutzdaten, das noch unter der alten Fritzbox 7390, bei der die CPU der noch limitierendere Faktor gewesen sein dürfte und noch lange nicht einmal 10 Mbit drin waren.

Ich hätte mir etwas mehr Ehrlichkeit von AVM gewünscht gegenüber den Kunden! Dass VPN immer langsamer als der native NAT-Durchsatz ist, das dürfte fast jedem klar sein. 20% Abzug, völlig normal.  Aber bei einer Diskrepanz von mehreren hundert Prozent, wenn man z.B. eine 50 oder 100 MBit Internetleitung betreibt und gerade mal 10 Mbit VPN-Durchsatz hat, da kommt man sich schon ziemlich „veräppelt“ vor, bei Hersteller-Aussagen, wie oben angeführt.

Die Zeitschrift C’t kommt mit den Durchsatzmessungen in Ausgabe 21/18 zu den selben Ergebnissen, wie meinen eigenen, als auch denen von Johannes Weber.

Ich tunnele nun mit OpenVPN und AES-NI-fähigen Prozessoren, damit ist der Durchsatz praktisch Wire-Speed (abzüglich Oberhead).

Utax Drucker und die Druckwarteschlange

Wie unter „https://www.nicht-trivial.de/index.php/2018/09/13/druckwarteschlange-stuerzt-unregelmaessig-ab/“ bereits angemerkt, stürzt auf einem Windows Server Betriebssystem unregelmäßig, aber häufig, die Druckwarteschlange ab. Und zwar sowas von „ab“, dass selbst Windows den Dienst selbsttätig nicht mehr startet. In einigen Fällen war sogar der Befehl „net stop Druckwarteschlange“ wirkungslos und produzierte nur den Ereigniseintrag (Eventlog) mit EventID: 7011 „Das Zeitlimit (30000 ms) wurde beim Warten auf eine Transaktionsrückmeldung von Dienst Spooler erreicht.“

Weiterhin sind gehäuft Meldungen mit EventID 1530 aufgetaucht:
„Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. “ betreffend \Device\HarddiskVolume1\Windows\System32\spoolsv.exe .

Bisher hatte ich die UTAX Druckertreiber in Verdacht. Der Verdacht hat sich nun erhärtet, als ich den Tipp bekam, den virtuellen Druckeranschluss (Standard TCP/IP Port) von RAW auf LPR umzustellen. Seither läuft die Druckwarteschlange stabil.

 

Druckwarteschlange stürzt unregelmäßig ab

Ein neuer Druckertreiber bringt offensichtlich den Spoolerprozess alias Druckwarteschlange unter Windows Server zum Absturz. Oder genauer gesagt wird die Druckwarteschlange in einen Zustand gebracht, in der sie nicht mehr reagiert, aber nicht ordentlich beendet wird. Das hat zu Folge, dass die Druckwarteschlange von Windows nicht als nichtfunktionierend erkannt und der Dienst neu gestartet wird. Supportanrufe diesbezüglich und manuelles Starten des Dienstes  lassen schnell nach Wegen suchen, die Sache automatisiert aus der Welt zu schaffen.

Die Lösung besteht derzeit daraus, ein Batch-Skript in Endlosschlaufe laufen zu lassen. Das Skript prüft auf Existenz eines vorhandenen Druckers. Wenn dieser nicht auffindbar ist, wird die Druckerwarteschlange neu gestartet.  Da rundll32 keinen auswertbaren Errorlevel zurück gibt, muss man über den Parameter /f eine Datei anlegen, welche als Indikator für den Fehlerfall dient. Bei jedem Neuaufruf der Skriptschleife wird die Datei (bei Existenz) wieder gelöscht.
Die Verzögerung wird über Pings an’s eigene System realisiert.
Ich setze zusätzlich noch eine „1“ per zabbix_sender an mein unabhängiges Monitoring-System Zabbix ab, um die Häufigkeit des Eingriffs mitzuloggen.

das Skript chkPrter.cmd:

@echo off
cls

SET PrinterName=Rechnungsdrucker
SET TESTfile=%TEMP%\PrtExist.txt

:start

REM Delete %TESTfile% to avoid false positives
IF EXIST „%TESTfile%“ (
DEL %TESTfile% /F /Q
)

REM Try to get the printer settings into a file
RUNDLL32.EXE PRINTUI.DLL,PrintUIEntry /Xg /n „%PrinterName%“ /f „%TESTfile%“ /q

IF EXIST „%TESTfile%“ (
REM ECHO Drucker %PrinterName% existiert
REM „C:\Program Files\zabbix\zabbix_sender.exe“ -z zabbixserver.local -s ServerXYZ -k serverZYX.printer.spooler -o 1 > NUL
) ELSE (
REM ECHO Drucker %PrinterName% existiert NICHT!
NET START Druckwarteschlange
REM „C:\Program Files\zabbix\zabbix_sender.exe“ -z zabbixserver.local -s ServerXYZ -k serverZYX.printer.spooler -o 0
)

ping -n 30 localhost > NUL

goto start