SSH Passwort die 1000te

P

Privateer

New Member
Hallo Kollegen,

wie wichtig erachtet ihr den strikten Zertifikatslogin ohne möglichen Passwortzugang per ssh? (Habe Debian 6 64bit vServer)

Alle preisen den Passwortlosen Zugang auf den Servern an und wie wichtig dieser ist, aber seien wir doch mal ehrlich, reicht es euerer Meinung nach, wenn der Root login deaktiviert ist und es nur einen Benutzer gibt der sich anmelden kann mit einem richtig sicheren Passwort?

Desweiteren interessiert mich die Bruteforce Geschwindigkeit die maximal erreicht werden kann Passwörter durchzuprobieren, damit mein ich die max. Geschwindigkeit für Schlüsseln pro Sekunde, wobei Fail2Ban installiert ist und nach dem zweiten Versuch die IP sperren sollte? (beispielsweise Botnetz, andere gekaperte Rootserver???)
 
Privateer said:
Desweiteren interessiert mich die Bruteforce Geschwindigkeit die maximal erreicht werden kann Passwörter durchzuprobieren,
Click to expand...

Das kannst Du an Hand der Anbindung Deines Servers selbst ausrechnen.

Hint: Es sind mehr als genug...
 
Ich verwende trotz der Warnungen, etc. noch einen Root-Zugang, da manches (SCP, etc.) dann nicht mehr richtig laufen und authentifiziere mich mit Passwort. Ich meine, ich habe eigentlich keinen Bock, wenn ich meinen PC neu installiere, dass ich meinen kompletten Server neu aufsetzen muss, da ich keinen Zugang mehr habe (das ist wiederrum übertrieben, aber wayne...) und wozu noch Sicherheit wenn dann viele wiederrum sagen "Speicher den auf USB", "Lad den irgendwo hoch", etc.? (Nicht hier aber in anderen Foren.)
 
Nun, ich betrachte den strikten Zertifikatslogin auf jeden Fall als wichtig und würde nach Möglichkeit versuchen, keine Passwort-Logins zu gestatten, allerhöchstens als Ausnahme für einzelne Benutzer. Zum PCFreund bleibt zu sagen, dass man den privaten Key wunderbar außerhalb des eigenen Rechners lagern kann bzw. sollte. So einen USB-Stick oder was du auch immer für ein Speichermedium verwendest lässt sich auch sicher genug einlagern.

Fail2ban würde ich glatt als Schlangenöl bezeichnen, wenn du den Login via SSH auf die Public-/Privatekey-Methode beschränkst kann es dir total egal sein, wie viele Versuche da durchgeführt werden. Die Warscheinlichkeit dass einer deinen privaten Key bruteforced ist einfach viel zu gering, dafür sparst du aber haufenweise an Leistung ein, weil Fail2ban nunmal nichts besser kann als Arbeitsspeicher und i/o-Performance ohne Gamin oder so schlucken.
 
Mein Server ist mit 100Mbit angebunden, sagen wir Fail2Ban funktioniert nichtmehr und der Angreiffer hat die volle 100Mbit Leitung zur Verfügung um Passwörter auszuprobieren.
Ehrlichgesagt weiß ich nicht wie man das ausrechnet (theoretisch ohne Verzögerungsdelay vom Server), vielleicht kann mir jemand auf die Sprünge helfen wie da die Rechnung aussieht?

Also wenn ich Schlüssel mit meinen 2x470 gtx Passwörter durchprobiere am Rechner komme ich gerade mal auf 56.000 Keys per Second und für mein verwendetes Passwort würde ich selbst mit gpu eine Ewigkeit benötigen
 
Last edited by a moderator:
Anmerkung: Wie denkt ihr darüber das man den Root login auf dem Server gestattet aber auf Zertifikatsauthentication beschränkt und Passwortzugang deaktiviert?
....wäre für meinen htc interessant da ich auf der kleinen touchtastatur nicht gerne lange Passwörter eingeben will um Root zu werden
 
...aber vermutlich wird vorher die CPU des Servers bremsen - denn der muss intern ja noch bei jedem Loginversuch anfangen Hashes zu berechnen und abzugleichen und das ganze noch ins Log schreiben u.s.w.
 
....

Also sollten es wirklich 30k Passwörter in der Sekunde sein, sind wir bei meinem gewählten Passwort noch Lichtjahren entfernt, wobei mir natürlich klar ist das die erste mögliche Eingabe richtig sein könnte.


Okay Passwort hin oder her, wenn ich ausschließlich die Passwortlose Anmeldung einrichte und nur über Zertifikate arbeite, kann ich dann den Root login erlauben, weil lange Passworteingaben um mit Sudo Root zu werden, auf dem htc Handy echt nicht schön sind??
 
Ich kenne niemand dessen Root-Passwort nennenswert sicher ist und welches mittels Bruteforce gecrackt wurde. In allen Faellen wo Root-Login entwendet wurde hatte der Betroffene zB aus dem Internet-Cafe im Urlaub "nur mal schnell" auf den Server geschaut was die Keylogger vermutlich freute.

Ich waehle fuer root selbst ein ellenlanges Passwort, waehrend die UID0-Accounts unter welchen ich arbeite einen anderen Loginnamen tragen. Damit ist ein normaler Bruteforce-Bot bereits bei weitem ueberfordert....
 
Erstmal vorweg, es wird im Rahmen von SSH häufig von "Zertifikatslogins" geredet. Es sind aber sicher keine Zertifikate im Spiel sondern asymetrische Schlüssel.

Ich verwende persönlich durchweg private Schlüssel, aber sehe das für den üblichen Hostingkunden als wenig praktikabel an. Man sollte seine Nutzer eher dabei unterstützen gute und lange Passwörter zu wählen, denn denen würde ich mehr trauen als ein SSH-Key ohne Passphrase der in der Kneipe am nächsten Morgen aufgefegt wird.

Leider fehlt mir selber noch ein Tool das sinnvoll die Stärke eines Kennwortes bewertet. Als ich anfing über Eingabemuster auf der Tastatur und Zusammenhang zum Benutzernamen nachzudenken, habe ich das aufgegeben sowas selber zu programmieren. :D
 
Wie denkt ihr darüber das man den Root login auf dem Server gestattet aber auf Zertifikatsauthentication beschränkt und Passwortzugang deaktiviert?
Click to expand...
Ich verbiete den Root-Login auf keinem meiner Server....
und denyhosts wacht über den Syslog :)

Saying "don't login as root" is horseshit. It stems from the
days when people sniffed the first packets of sessions so logging in
as yourself and su-ing decreased the chance an attacker would see the
root pw, and decreast the chance you got spoofed as to your telnet host
target, You'd get your password spoofed but not root's pw. Gimme a
fucking break. this is 2005 - We have ssh, used properly it's secure.
used improperly none of this 1989 bullshit will make a damn bit of
difference.
Click to expand...
Quelle: http://archives.neohapsis.com/archives/openbsd/2005-03/2878.html

Und für "sichere" Passwörter gibts ja auch noch pwgen :D

Und wenn mir das immer noch nicht reichen sollte, so würd ich die Verbindungsverusche einfach per iptables limitieren

Code: 
#!/bin/bash
inet_if=eth1
ssh_port=22
$IPT -I INPUT -p tcp --dport ${ssh_port} -i ${inet_if} -m state --state NEW -m recent  --set
$IPT -I INPUT -p tcp --dport ${ssh_port} -i ${inet_if} -m state --state NEW -m recent  --update --seconds 60 --hitcount 5 -j DROP
 
Wer schlau und sicherheitsbewusst ist, überprüft mal den eigenen Passwortgenerator mit John-the-Ripper und anderen Zerknackern. ;)
 
Joe, bei pwgen kommt es, wie sonst auch, auf die Länge an :D

pwgen 20 , und schon wird das Bruteforcen zum Unding....
Um den eingeschränkten Zeichenumfang mache ich mir da ehrlich gesagt keine Sorgen, der Angreifer hat ja keine Ahnung wie ich die PWs erstellt hab.

Dazu ein Ausschnitt aus der pwgen Man-Page
In particular, passwords generated by pwgen without the -s option should not be used in places where the password could be attacked via an off-line brute-force attack.
Click to expand...

Und den Hash des Root-Passworts sehe ich nicht als Offline attackierbar an (ausser das System ist sowieso schon kompromitiert).
 
Zusammengefasst kann man also sagen das man den Root login nicht verbieten braucht WENN man Zertifikate bzw. Schlüssel verwendet und die Passwortanmeldung ausschaltet?

Vielleicht bin ich auch zu paranoid aber in anderen Foren wird man gleich mit demotivierenden postings niedergemacht von wegen "wieder ein Server mehr der am Botnetz hängt". :p
 
Ignorieren, du weisst es nun besser ;)

Oder als Gegenargument, rate ihnen doch einfach mal einen Server aufzusetzen der nur durchs Root Passwort geschützt ist. Da sieht man dann wie sicher diese Methode wirklich ist :)
 
You must log in or register to reply here.
Back
Top