Unattended Upgrades zerschießt sshd_config. Falsch konfiguriert?

  • 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?

  • Es gibt hierzu einen Bugreport: Bug#942100: openssh-server: /etc/ssh/sshd_config unconditionally overwritten by update.

    Eine generische Absicherung gegen derartige Fehler zu empfehlen ist schwierig, da ein Überschreiben wirklich niemals vorkommen sollte, Modifikationen jedoch schon – blockiert man das eine, dann auch das andere. Verzögert man "unattended updates" in der Hoffnung, dass evtl. Fehler zwischenzeitlich behoben wurden, ist die Frage, welche Frist man hier ansetzen will (auf den obigen Fehlerreport hat nach knapp einer Woche bislang niemand auf der Mailingliste reagiert); und im Zweifelsfall muss man dann bestimmte Pakete doch im Auge behalten, was das zugrundeliegende Konzept der vorgenannten Updates teilweise aushebelt.

    Man kann jedoch in solchen Fällen unter anderem die Restaurierung von alten Konfigurationen erleichtern durch Installation von etckeeper.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing