Hi ENOLINK,
danke für die Bestätigung, dass es nicht nur bei mir auftritt. Ein geistesabwesender reboot meines VPS hat mich auch schlagartig daran erinnert, dass ich das Problem noch habe und bislang keine zufriedenstellende Lösung gefunden habe.
Würde mich sehr freuen, wenn jetzt auch von offizieller Seite mal eine Stellungnahme kommen würde (Problem (an)erkannt, Lösungsvorschläge, etc.).
Grüße,
Moin!
Ich wollte ich gerade nach einigen Tagen mal wieder in meinen VPS einloggen und musste mich doch stark wundern, dass mein server nicht mehr auf den von mir konfigurierten Port reagierte, sondern stattdessen auf den default port 22 lauschte und mir doch auch gleich eine warning "host key has changed" entgegenschleuderte. Ich konnte mich auch nicht erinnern, den key schon mal gesehen zu haben.
Naja nach etwas zögern und misstrauen, habe ich mir überlegt, dass die Chancen, einem Angriff zum opfern gefallen zu sein, doch sehr gering waren und ich auch nicht viel zu verlieren hatte, sollte ich mich nun auf einen rouge server einloggen (key-based auth). Kaum eingeloggt, habe ich erst mal die keys des ssh daemon verglichen und tatsächlich gab es neue keys vom verfahren ECDSA (ich nutze sonst ed25519) und die sshd_config sah auch nach Stock aus. Ich habe dann mal einen Blick in die logs von apt und dpkg geworfen und festgestellt, dass das packet "unattended-upgrades" am 08. Oktober security patches für openssh-sftp-server (openssh-server) eingespielt hat, welche wohl meine config überschrieben haben und ECDSA keys zum standard gemacht haben. Soweit erst mal erleichtert, dass es kein böser Angriff war, war ich doch etwas überrascht, dass da ein Dienst ohne mein zutun meine sshd_config überschreibt, und mich so potentiell auch aussperren kann.
Normalerweise spiele ich immer selber fleißig updates ein, und bei einer Kollision würde apt ja nach einem merge fragen. Hier scheint aber nun einfach die maintainers version genommen zu werden (macht wohl auch Sinn, schließlich geht es um potentiell kritische Sicherheitslücken).
Dennoch frage ich mich, ob da auf meinem Debian Buster alles so eingestellt ist, wie es sein sollte. Hat jemand vielleicht ähnliches erlebt oder TIpps, wie ich dem in Zukunft vorbeugen könnte?
Steini danke für den Tipp! und schön, dass du aus meinem Post was lernen konntest 
Da ich mit meinem workaround aktuell ganz gut leben kann, hats mit der Aufklärung des Problems auch keine große Eile, deswegen dachte ich mache ich das mal in einem öffentlichen Forum, wo vielleicht der eine oder andere noch was Beitragen oder mitnehmen kann.
H6G vielleicht wird sogar Broadcast traffic aktiv für die Kunden IPs gefiltert? Mich würde es dann doch noch mal jucken rauszubekommen was in Stretch anders war, dass es damals funktioniert hat oder ob die Netzwerkregeln wohl genau in dem Zeitraum umgestellt worden sind?..
Moin zusammen,
ich habe die letzten Tage ein etwas eigenartiges Problem debugged, welches aufgetreten ist, nachdem ich meinen Debian Stretch server auf Buster upgraded habe. Dabei schlägt die Netzwerkkonfiguration während der initramfs phase des Bootprozesses fehl, da der Netcup server nicht auf Discovery Requests des verwendeten dhcp clients ipconfig antwortet.
Hier ein paar nähere Details: Wie die meisten Linux Admins ja wissen dürften, wird im Boot Prozess ein minimalistisches filesystem, das initramfs in den Speicher geladen, um einige Schritte, wie z.B. das entschlüsseln einer LUKS Partition vorzunehmen. Netzwerkzugang wird während der Phase eher selten benötigt, aber z.B. bei PXE boots (afaik) und z.B. wenn man das initramfs mit einem dropbear ssh Server ausstattet, um per SSH den Disk Key für LUKS eingeben zu können (anstatt immer per SCP VNC verbinden zu müssen).
Im diesem Falle wird in der Regel die Shell Funktion configure_networking im /scripts/functions Shell Script ausgeführt, welches die Kernel Options (speziell die IP option) checkt und das Netzwerkinterface entsprechend konfiguriert. Standardmäßig ist dafür DHCP eingestellt.
Dafür verwendet die Funktion das klibc-utils tool ipconfig, welches einen minimalistischen DHCP client implementiert. Wie man den angehängten network traces entnehmen kann, antwortet zuständige Netcup DHCP Server nicht auf den Request von ipconfig. Ein anderes, minimalistisches DHCP Tool, udhcpc aus der Busybox, welches ebenfalls im initramfs zur Verfügung steht hat einen minimal anderen Request und darauf antwortet der Server.
Es sind bei Debian und Ubuntu ein Bug bekannt gewesen, (im PXE usecase) bei dem festgestellt wurde, dass die DHCP Implementierung von ipconfig minimal falsch ist, sodass gewisse pingelige DHCP server die Antwort verweigern. der Bug wurde jedoch eigentlich längst gefixt und ich kann beim angucken des Request Packets auch nichts ungewöhnliches entdecken.
Ein workaround ist die statische Konfiguration mittels Kernel Option IP, aber ich würde mich riesig freuen, wenn die Netcup Admins der Sache mal nachgehen könnten. In einer lokalen VM konnte antwortet der VMware DHCP Server nämlich problemlos auf das selbe Paket.
Wer es selber mach testen möchte, kann dies auch nach dem Boot machen, das ipconfig binary liegt in /usr/lib/kblic-utils/bin (oder so).
PS: Vielleicht kann ein Mod ja auch mal ein Sticky im Forum anlegen, dass man sein Konto im CCP verknüpfen muss, habe einen Tag auf eine Freischaltung durch einen Mod gewartet ^^..
