Kein Login per SSH

  • Ich richte gerade meinen ersten Rootserver bei NetCup ein, habe Debian 9 neu installiert.


    Über die VNC-Simulation des SCP kann ich mich als root (mit Passwort) einloggen, aber nicht mit einem normalen SSH-Client. Woran könnte das liegen?


    Natürlich will ich schnellstmöglich das Passwort-Login abschalten, aber da im VNC kein Copy & Paste funktioniert, bekomme ich meinen Public Key da auch nicht rein.

  • Best Practice ist klarerweise kein Root-Login, kein Passwort-Login, Login nur über 3000+ bit RSA oder besser noch Ed25519 pubkey.

    Ist das so? "klarerweise"??

    Kommt immer auf den Anwendungsfall an! Ich sehe sudo also zusätzliche Software und damit zusätzlichen Angriffsvektor der (mir) keinen Sicherheitsgewinn bringt. Außer: "Der Angreifer müsste sonst noch den Nutzernamen erraten." Aber mal ehrlich, wer eine pubkey Verbindung knacken kann lässt sich von einem Nutzernamen nicht aufhalten (wird ja auch mit übertragen).

    Es gibt tatsächlich valide Argumente gegen root Zugriff, zum Beispiel wenn(!) mehrere Personen Adminzugriff haben.

    # Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:

    # On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.
    # Additionally, only tools such as systemd and auditd record the process session id.
    # On other OSes, the user session id is not necessarily recorded at all kernel-side.
    # Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.

    Das ist bei mir aber nicht der Fall. Ich halte es für problematisch sowas pauschal zu sagen ohne den Nutzen zu erläutern. So denken viele User/Freizeitadmins "Hey, ich habe den Port geändert, nutze (irgendwelche) Keys und habe den Rootzugang deaktiviert, ich bin ultimativ safe".

    Es gibt aber tatsächlich viel wichtigere Dinge um die man sich kümmern müsste, einen root account zu haben ist nunmal _kein_ Sicherheitsrisiko! Wer die Sicherheit erhöhen will soll halt Mehrfaktorauthentifizierung implementieren (wieso wird das nie genannt?), per VPN verbinden und nur bestimmte IPs zulassen (generell wer Zugriff auf feste IPs hat, die halt eintragen), etc...


    Ganz wichtig aber, auf sichere Verschlüsselung setzen. die Standardeinstellungen der meisten Distributionen sind nicht gut genug:


    Best practices:

    https://infosec.mozilla.org/guidelines/openssh

    https://stribika.github.io/201…/secure-secure-shell.html

  • Seit über 20 Jahren kann man sich auf fast all meinen Servern via SSH als root einloggen, ... bei ausreichend sicherem Passwort, bzw. Key sehe ich da nach wie vor kein großes Problem. Sorry wollte ich nur mal wieder anmerken 😂😘

  • einen root account zu haben ist nunmal _kein_ Sicherheitsrisiko!

    UID & GID 0 ist ein Sicherheitsrisiko.


    Die können nämlich so wichtige Sachen machen, wie:

    • bestimmte Daten lesen & schreiben
    • Ports unterhalb von 1024 binden
    • iptables manipulieren

    Wenn ich mich mit einem sshd auf meinem System unter Port 22 verbinde, so kann ich mir sicher sein, dass dieser sshd nur vom root User stammen kann, und keinem anderen.

    Wenn ich dafür sorge, dass kein Dritter diesen Root Zugang benutzt hat, kann ich der SSH Verbindung immer vertrauen.


    Ich sehe sudo also zusätzliche Software und damit zusätzlichen Angriffsvektor

    sudo ist ein zusätzlicher Verteidigungsvektor, mit dem ich die Kommandos und Argumente von Programmen die unter UID 0 ausgeführt werden können, für einen definierten User präzise einschränken kann.


    Für deinen Fall: mir klaut jemand den private Key, dann kann er mit meinem Account noch nix anfangen, weil er die falsche UID hat.

    Der Angreifer hat dann Zugriff auf meinen Homefolder, und kann in einer Sitzung höchstens meine Shell manipulieren.

    Klaut mir jmd. den private Key für den root User kann ich nichts weiter machen.

  • Wenn ich dafür sorge, dass kein Dritter diesen Root Zugang benutzt kann ich der SSH Verbindung immer vertrauen.

    Und ich dachte, wenn ein Dritter den root Zugang benutzt wäre die SSH Verbindung das kleinste Problem. Dummes ich ...

    sudo ist ein zusätzlicher Verteidigungsvektor, mit dem ich die Kommandos und Argumente von Programmen die unter UID 0 ausgeführt werden können, für einen definierten User präzise einschränken kann.

    Irgendwann wirst du deinen Server auch mal verwalten müssen und dafür root brauchen. Die gewonnene Sicherheit durch deinen zusätzlichen Verteidigungsvektor rechtfertigt (für mich) in keiner Weise den zusätzlichen Aufwand und Komfortverlust. Zweifaktorauthentifizierung hilft deutlich mehr und schränkt weniger ein.

    Für deinen Fall: mir klaut jemand den private Key, dann kann er mit meinem Account noch nix anfangen, weil er die falsche UID hat.

    Weil der Angreifer, der in der Lage ist deinen Key zu klauen noch nie was von sudo gehört hat und damit nicht umgehen kann?

    Hast du 2FA, kann er auch mit deinem Key nichts anfangen.


    Offensichtlich gibt es dafür nur "religiöse" Argumente und da lässt sich nicht gegen Argumentieren. Würde mich aber dennoch mal für eine Geschichte interessieren, wo jemandem der Key gestohlen wurde und der Server dann nicht übernommen wurde, weil es nur ein normaler user war (der per sudo dennoch alles machen kann).


    Edit: Zugegebenermaßen ist 2FA mit Hardwaretokens für SSH momentan noch nicht so einfach umzusetzen wie das wünschenswert wäre. Aber passend dazu: https://marc.info/?l=openssh-unix-dev&m=157259802529972&w=2

    Mit Google-Authentifikator (wenn man dem denn vertraut) gehts recht fix: https://hackertarget.com/ssh-t…tor-google-authenticator/

  • Schonmal was von User-Passwörtern gehört?

    Habe ich. Ist am Ende aber auch wieder nur ein weiteres Passwort, dass entweder kurz ist oder umständlich. Und von der Sicherheit her schwächer als ein Einmalpasswort bei 2FA (oder zweifelst du das etwa auch an?). Insbesondere, weil die 2FA dafür sorgt, dass der Angreifer erst garnicht auf den Server kommt und das Userpasswort nur, dass der Nutzer nicht gleich root ist (in den seltensten Fällen aber verhindert, dass ausführbarer code nachgeladen wird, etc...)

    Finde ich ja toll: Es gibt deutlich sicherere moderne Methoden, aber es wird vehement also non-plus ultra verteidigt, was zwar vor 10 Jahren top war aber jetzt nur noch gut.

  • Also ich fahre eigentlich ganz gut mit root login und non default ssh port. Aber hey... was weiss ich schon ;)


    Edit: Was rede ich denn da... User Login natürlich. Und per separatem PW nach Root. Aber ist auch kein hochnotpeinliches System sondern nur eine Dateiablage und um ab und an Dinge zu testen.

  • Habe ich. Ist am Ende aber auch wieder nur ein weiteres Passwort, dass entweder kurz ist oder umständlich. Und von der Sicherheit her schwächer als ein Einmalpasswort bei 2FA (oder zweifelst du das etwa auch an?). Insbesondere, weil die 2FA dafür sorgt, dass der Angreifer erst garnicht auf den Server kommt und das Userpasswort nur, dass der Nutzer nicht gleich root ist (in den seltensten Fällen aber verhindert, dass ausführbarer code nachgeladen wird, etc...)

    Finde ich ja toll: Es gibt deutlich sicherere moderne Methoden, aber es wird vehement also non-plus ultra verteidigt, was zwar vor 10 Jahren top war aber jetzt nur noch gut.

    Passwörter können auch lang und merkbar sein ;)


    Den Sinn von 2FA zweifel ich nicht an.

    Jedenfalls bietet die Nutzung eines vernünftig konfigurierten sudo m.M.n. mehr Vor- als Nachteile.


    LG

    Alex

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    www.jeff24.de | RS2000 Plus, VPS2000 Plus, 2xVPS500, 2xVPS200, EiWoMiSau

  • Ich frage mich gerade nach einem möglichen Szenario gegen die einzelnen Sicherheitsmaßnahmen:

    1. Langes Passwort, Wartezeit (Brute-Force unmöglich) und root login

    Das Passwort muss abgefangen werden.

    Möglich durch eine Phishing Attacke, sehr unwahrscheinlich, dass ein Admin so dumm ist.

    Möglich, wenn man sich auf fremden oder öffentlich zugänglichen Geräten einloggt. (Keylogger, bspw. am USB Port)

    Möglich, wenn man auf den Clients keine AV Software hat oder Staatsfeind #1 ist.

    Möglich, wenn man sein PW anderen verrät oder in der Cloud "sichert"


    2. Key-Auth und root

    Der Key und UID muss gestohlen werden.

    Möglich, wenn man sich auf fremden oder öffentlich zugänglichen Geräten einloggt. (Dateien werden kopiert)

    Möglich, wenn man auf den Clients keine AV Software hat oder Staatsfeind #1 ist.


    Pauschal gesagt, beide Fälle 1 und 2 sind ähnlich schlecht, da beides mal unbemerkt der Zugang kopiert werden kann. Fall 2 vielleicht ein bisschen sicherer, da man nicht einfach über die Schulter das PW mitschreiben kann, sofern man überhaupt das PW in aller Öffentlichkeit eingibt. Der Nachteil von 2 ist aber die Bindung ans eigene Gerät, wenn man den Private Key nicht gerade auf einem USB Stick umherspazieren will. Den kann man zwar verschlüsseln, dann sind wir aber wieder bei genau 1.


    3. Key-Auth und sudo

    siehe 2. Wenn derjenige schon in der Lage ist, den private key zu stehlen, dann wird es, denke ich, ein leichtes sein, auch das User Passwort zu stehlen.


    4. 2FA und root.

    Tan Generator muss gestohlen werden. Das fällt auf.

    Vorteil ist, problemlose Anmeldung auf Fremdgeräten und in aller Öffentlichkeit. Kurze Passwörter möglich.

    Nachteil: Gebunden an mich, im Falle eines Todes / Unglücks ausgesperrt?

    Wobei: Ernsthafte Frage: Wie kann ich mich im Falle eines Diebstahls/Defekts des Tan Generators dann noch auf einen Netcup Server bspw. einloggen, um schlimmeres zu verhindern? Nur noch per VNC im SCP mit ganz normalen Passwörtern?


    Weitere Frage: Wenn ich mich sowieso nur daheim einlogge, in meinen sicheren vier Wänden, dann suche ich gerade ernsthafte Vorteile von diesen ganzen weiteren Mechanismen. Ist jemand auf meinem PC und kann viele Tage/Wochen alles mitlesen, dann ist doch alles ausgehebelt. Spätestens, wenn man sich am SCP mal anmeldet.


    Ich bin kein Experte, daher mag auch manches falsch sein, bitte freundlich berichtigen. ;)

  • Was läuft denn sonst noch so auf dem Server? SSH ist in der Regel deine kleinste Sorge. Wenn da ein veraltetes Wordpress mit einer veralteten PHP Version (bei Debian nicht unüblich), dann wird sich ein Angreifer nicht auf SSH konzentrieren. Wenn da eine Ruby on Rails Applikation mit hunderten Ruby Modulen läuft, dann ist SSH deine kleinste Sorge. Wenn du Teamspeak oder einen Game Server betreibst, dann ist SSH nicht das primäre Angriffsziel. Du merkst schon worauf ich hinaus möchte. OpenSSH ist eine robuste und stabile Software. Mit Key only Auth fährt man da schon ausreichend sicher. Verliere nicht den Blick für die eigentlich wichtigen Dinge.

  • Ist das so? "klarerweise"??

    Ja, bei sicherheitsbewussten Admins schon. Das ist best practice seit vielen Jahren wie du selbst zitierst hast.


    Root user ist der erste Account den ich sperre, u.a. aus den von dir zitierten Gründen.

    Alles was mit root-Rechten ausgeführt wird auf meinen Systemen auch fein säuberlich mitgeloggt und das nicht nur aus Sicherheitsgründen.


    Das mit dem 3000+ bits RSA oder Ed25519 Schlüssel sollte auch selbstverständlich sein, denn damit hat man eine Sicherheit von 256+ bits. Auch schon seit Jahren Empfehlung.

    Natürlich kann man auch ein entsprechend langes und komplexes Passwort verwenden, aber da man sich das wahrscheinlich nicht merken kann und auch nicht händisch eintippen will, kann man auch gleich pubkeys verwenden.


    Quote

    Ich sehe sudo also zusätzliche Software und damit zusätzlichen Angriffsvektor der (mir) keinen Sicherheitsgewinn bringt.

    Ich sehe es gegenteilig.
    Der root user ist der zusätzliche Angriffsvektor. Über den login. Ebenso über su...

    sudo verwendet auch nur pam und wenn da eine Lücke ist, dann ist sowieso schon alles egal.

    sudo ermöglicht auch noch zusätzliche Einschränkungen, die sonst nicht möglich sind bzw. mit root einfach umgangen werden könnten. Wie du richtig schreibst, ist das z. B. bei mehreren Admins äußerst nützlich.


    sudo zieht auch noch eine zusätzliche Sicherheitsschicht ein: Selbst wenn jemand Zugriff auf meinen Server mit meinem Admin-User hätte, dann bringt ihm das nichts, denn er müsste immer noch das Benutzerpasswort erraten ... und dank pam_faillock sind Brute-Force-Attacken hier ebenso unmöglich.
    Das wird natürlich auch geloggt.

    Quote

    So denken viele User/Freizeitadmins "Hey, ich habe den Port geändert, nutze (irgendwelche) Keys und habe den Rootzugang deaktiviert, ich bin ultimativ safe".

    Aber von irgendwelchen Keys war auch nie die Rede.

    Den Port zu ändern ist nur security through obscurity, also kein echter Sicherheitsgewinn. Ich verwende den Standardport, nur ist dieser halt nur für mich offen.

    Was aber auf jeden Fall hilft, ist den Rootzugang zu deaktivieren. :P

  • Ich sehe es gegenteilig.
    Der root user ist der zusätzliche Angriffsvektor. Über den login. Ebenso über su...

    sudo verwendet auch nur pam und wenn da eine Lücke ist, dann ist sowieso schon alles egal.

    Ich weiß, ich sollte auf den Thread nicht mehr antworten. Ich werde mich bessern, versprochen ...

    Ich will nur noch einen Link dalassen um zu zeigen, dass es in sudo auch durchaus Lücken geben kann (und gab!), die nicht durch pam kommen. Natürlich sind die mittlerweile geschlossen, aber wer weiß was morgen kommt? Jede zusätzliche Software hat potentiell zusätzliche Sicherheitslücken. Und sudo verwendet nicht "nur" pam, sondern ist relativ komplex:

    https://www.sudo.ws/sudo/alerts/
    Ganz klar kann der Einsatz von sudo Sinn machen (je nach Anwendungsfall), aber wer es nicht benutzt ist auch nicht per se ein Sicherheitsrisiko. Hier wird so getan, als wäre es unverantwortlich, sudo nicht zu benutzen und das ist einfach Murks. Best Practice ist heutzutage die 2FA (und morgen mittels FIDO2)!