SSH passwort/public key

CEW4

Member
Hallo zusammen,

ich habe eine Frage zum Umgang mit SSH, die Ihr bestimmt aus dem Handgelenk beantworten könnt:

Ich habe den root-Zugang auf einem vServer von Passwort- auf Authentisierung über Public Key umgestellt. Warum sollte ich jetzt den Zugang über Passwort deaktivieren?

Ich sehe als einzige Gefahr, daß jemand über einen Einbruch die Passwort-Liste des Systems bekommen könnte. Aber dort liegt ja nur ein Hash des Passworts (oder? Wie kann ich das eigentlich überprüfen?), und das Passwort ist relativ lang (länger 20 Zeichen.) Sollte das nicht sogar in Zeiten von Cloud-Cracking für den Augenblick noch sicher sein?

Oder gibt es ein weiteres Risiko, das ich übersehe?

MfG
 
wenn jemand aud deinem System ist, ist es ihm relativ egal, was du benutzt, denn in dem Moment, wo er die Hashes anschauen kann, ist er normal schon Root.
Geundsätzlich ist ein Key auch nicht sicherer als ein Passwort.
Das Argument mit dem Keylogger ist keins, denn ein Keylogger kann sowohl das Passwort mitschneiden, als auch den Key und das dazugehörige Passwort
 
Das Argument mit dem Keylogger ist keins, denn ein Keylogger kann sowohl das Passwort mitschneiden, als auch den Key und das dazugehörige Passwort
Nicht bei Hardware-Keylogger welche selbst in gesicherten Rechnerpools mit Betriebssystem-Reinstallation und anderem Schnickschnack ein reales Risiko darstellen. Eine Uni hier in der Gegend kämpft aktuell konstant damit dass jemand Hardware-Keylogger (sehen aus wie ein kleiner Usb-Stick nur mit einem USB-Ausgang hinten wo das Kabel der Tastatur angeschlossen wird) anbringt.

Allerdings kann man Hardware-Keylogger dadurch umgehen dass man nur vertraute Rechner verwendet (Stichwort Laptop) oder -ironischerweise- Passwortdatenbanken respektiv on-screen Eingabe.
SSH kann man übrigens mit Google Authenticator absichern falls man diese zusätzliche Sicherheit will.
Allerdings helfen alle Methoden nur dagegen dass ein Angreifer nicht zu späteren Zeitpunkten das Passwort missbrauchen kann - bei kompromittierten Systemen ist eine Injektion von Befehlen in das offene Fenster immer möglich und dank der Tatsache dass so ziemlich jeder die gleiche Software (Putty) verwendet leicht programmierbar.

Aber dort liegt ja nur ein Hash des Passworts (oder? Wie kann ich das eigentlich überprüfen?)
Mit "cat /etc/shadow"
Das Passworthash wurde vor längerer Zeit -entgegen der Meinung einiger Verfechter der Kerkhoff-Definitionen - aus der global lesbaren /etc/passwd in die nur von superuser lesbare /etc/shadow verschoben. Das ist auch der Grund warum zB passwd das SUID-Flag brauchen.


Falls man eigene Rechner verwendet ist die Probabilität (bei sicherem Passwort) dass dieses geknackt wird ungefähr gleich hoch als bei Keys - da eigentlich nur der Weg über Trojaner bleibt.
 
Siehe hier: http://en.wikipedia.org/wiki/Passwd
Unter aktuellen Systemen ist es generell Nr.6, also SHA512

Nebenbei; einige Umgebungen und Panels (zB Froxlor) konfigurieren standardmässig die Systemdienste wie FTP mit dem uralten und gewollt (aufgrund von Exportbeschränkungen) unsicheren Algorithmus crypt welcher nur die ersten 8 Stellen von Passwörter berücksichtigt
 
Ich habe den root-Zugang auf einem vServer von Passwort- auf Authentisierung über Public Key umgestellt. Warum sollte ich jetzt den Zugang über Passwort deaktivieren?

Weil man ein Passwort per Bruteforce knacken kann. Und wo kein Passwort erlaubt ist kommt auch kein Bruteforce durch.
 
Keys auch. Ob man paar tausend oder paar Millionen Jahre dran arbeitet ist eigentlich für meine Büchse die alle paar Jahre ein neues root-Passwort kriegt irrelevant. Und meine Ur-ur-ur-ur-ur-ur-ur-ur-ur-^99-Enkel können sich um ihre eigenen Probleme kümmern :D
 
Ich denke diese Problematik ist, wie vieles andere auch, eine Glaubensfrage.
Analog zum Thema "Permit root login", was zu Telnet-Zeiten noch absolut empfehlenswert war.
 
...Ich sehe als einzige Gefahr, daß jemand über einen Einbruch die Passwort-Liste des Systems bekommen könnte. Aber dort liegt ja nur ein Hash des Passworts (oder? Wie kann ich das eigentlich überprüfen?), und das Passwort ist relativ lang (länger 20 Zeichen.) Sollte das nicht sogar in Zeiten von Cloud-Cracking für den Augenblick noch sicher sein?...
Bei einer kleineren Maschine könnten auch Performance-Gründe ein Argument sein, denn es wird ja jedesmal die Gültigkeit des Logins geprüft. Wenn Du PW-Login deaktivierst, wird die Verbindung praktisch sofort abgelehnt.
 
Back
Top