SSH root login unterbinden

  • Du loggst dich dann ja zukünftig mit einem neuen Benutzer ein.


    Für einen Befehl, welcher als Root-User ausgeführt werden soll je nach eingesetztem System einfach dem Befehl ein su (bei Debian) bzw. sudo (bei Ubuntu) voranstellen, dann wirst du nach dem rootpasswort gefragt.


    Entspricht quasi der Funktion ,,als Administrator ausführen" von Windows

  • Hm ich kenne sudo, da ich Arch Linux als mein System zum Arbeiten nutze.


    Soll ich den neuen Nutzer einfach in /etc/sudoers eintragen? Soll dieser auch die gleichen Rechten bekommen wie root?


    Ich frage, weil ich nicht genau weiß, was diese Sicherheitsmaßnahme bezwecken soll, außer, dass der Name des Administratoren geändert wird. Gehe ich recht in der Annahme?

  • Ist so nicht richtig. Welche Distribution nutzt du?


    Es heißt auch bei Debian sudo. su ist immer das Tool zum Benutzerwechsel.


    Umbenannt wird da auch nichts.


    Unter Debian z.B. fügst du denn sudo user in die Gruppe sudo hinzu, unter Fedora zu wheel. Dann können die Nutzer sich, wenn benötigt, Superuser Rechte abholen.


    Sinn des ganzen ist es, nicht immer sofort mit Superuser Rechten auf dem System rumzuspringen. Und auch einem Eindringling es nicht zu einfach zu machen.


    Da der Superuser immer root heißt muss er bei einer Kiste mit offenem root-login nur noch das Passwort bruteforcen und ist anschießend sofort mächtigster User des Systems. Ohne aktivieren root-ssh muss er zusätzlich erst mal einen Benutzernamen heraus finden, mit dem er ins System kommt. Und selbst wenn er auch dort dann durch kommt: Immerhin ist er nicht sofort Superuser.

  • Einerseits wird bei su und sudo noch einmal ein Passwort abgefragt. Anderseits kann es dich vor fehlerhaften Befehlseingaben schützen, wenn du nicht root bist (als root kannst du selbst wichtige Systemdateien löschen, als unprivilegierter User nicht).

  • Hay,


    und Du kannst es nochmal schwieriger machen - mein Nutzer, der sich root-Rechte nehmen kann, darf sich nur mit Keyfile anmelden, welches wiederum mit einer umfangreichen Passphrase geschützt ist.


    Und trotzdem ist nach erfolgreichem Login noch einmal su für root-Rechte notwendig - mit nochmal Kennwort.


    Und dann nochmals fail2ban drüber, wobei ich die Logfile-Hygiene durch die Blockierung nach 5 Erfolgversuchen fast noch mehr schätze als das Blocken an sich 8o. Ist halt nervig, wenn man was schraubt und das syslog durchscrollt, weil jemand gerade sein Hackerscript laufen hat, welches alle potenziellen Standarduser und die beliebesten Namen durchprobiert...


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Ich habe das Problem etwas anders gelöst:

    Ich habe per iptables/ip6tables den SSH Zugang komplett gesperrt (Default ist REJECT, nur ausgewählte Ports erlaubt).


    Es gibt nur 2 Ausnahmen:

    - Der Port Knocker daemon knockd kann eine Ausnahme für eine einzelne IP anlegen, wenn ich über eine bestimmte Sequenz anklopfe.

    - Zugriffe über das VPN (StrongSwan + Zertifikate) sind grundsätzlich erlaubt.


    Vorher hatte ich das Problem, dass mein Server permanent von externen Seiten per Brute Force angegriffen wurde. Durch diese Lösung ist das Auth-Logbuch nun nahezu leer...