Neuer Fingerprint bei jedem Connect

str0x3r

New Member
Hallo!

Seit heute merke ich, dass ich jedes mal wenn ich mich via Putty an der SSH anmelde oder WinSCP/Filezilla benutze, um mich per SFTP anzumelden, die Warnmeldung bekomme, dass der Fingerprint des Servers nicht übereinstimmt.

Mein Server läuft auf Ubuntu 10.10 Maverick mit nginx, php-fpm & mysql.

An der SSH-Config wurde nichts verändert.
 
Ja, die meine ich.

Und nein, letzte Neuinstallation ist jetzt schon ca. 2 Tage und gefühlte 2.000 Verbindungen her. :confused:
 
Gehst du auf deinen Server, guckst du in der sshd-config, welche öffentlichen Schlüssel verwendet werden, zeigst du Fingerprint mit:

Code:
ssh-keygen -l -f SCHLÜSSELDATEI

Ist der Fingerprint identisch mit dem von putty angezeigten, hat putty einen alten Key im Cache und alles ist in Ordnung. Sind die Keys nicht identisch, gab es einen Man-In-The-Middle-Angriff und du hast dein Passwort an einem fremden Host eingegeben.
 
Unter Debian / Ubuntu

Code:
cat /etc/ssh/sshd_config 
# Package generated configuration file
# See the sshd_config(5) manpage for details
[...]
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
[...]
 
Gut die beiden Keyfiles hab ich mir mal mit "cat" angesehen, ist aber natürlich nur gewirr. Letzte frage daher (hoffentlich), wie kann ich die mit den Keys von Putty vergleichen?
 
Den Key vom Server hab ich jetzt schon. Nur den von Putty, wie bekomm ich den in ein brauchbares "Format"?
 
Du brauchst nicht den Key, sondern den FINGERPRINT! Den zeigt dir Putty ja im Regelfall an. Den Fingerprint vom Keyfile erhältst du mit o.s. ssh-keygen-Befehl.
 
Dann solltest du aus Sicherheitsgründen nun trotzdem das Passwort ändern und sicherstellen, dass du noch Herr deines Servers bist.
 
Wenn es wirklich so war, dass ohne jede Änderung von dir putty ein paar Mal über den Fingerprint gemeckert hat und es nun wieder ohne Interaktion deinerseits nicht mehr meckert, dann hast du ein wirkliches Problem!

Dann kannst du davon ausgehen, dass dein Passwort per Man-In-The-Middle abgeschnorchelt wurde und schon seit einiger Zeit Leute Zugriff auf deinen Server haben.

In diesem Fall hilft auch kein Passwort ändern, da möglicherweise Backdoors installiert wurden sind.
 
Schon längst erledigt. Ich glaube, ich werde noch ein paar Änderungen vornehmen...ich meine ich bins gewohnt 2 Stunden nach Setup bereits SANS.DFIND in meinen Webserver-Logs zu sehen, aber so ein grotesker stündlicher Wechsel von RSA-Keys ist mir noch nicht untergekommen.
 
Es gilt wie immer: Wenn Fremde Root-Zugriff auf den eigenen Server hatten und dort in der Lage waren, Kommandos auszuführen, dann KANN! man dem eigenen Server nicht länger vertrauen. Passwort ändern bringt da nix mehr, weil du nicht feststellen kannst, was da alles auf dem Server passiert ist.
 
Das Kind ist schon in den Brunnen gefallen.

Nur soetwas ist mir noch nicht untergekommen:

/etc/1/1/1/1/1/1 - lauter leere ordner.
/etc/2/2/2/2/2/2 - usw...

wie viele es genau sind? nicht nachgezählt.

Server in den Rescue geschickt. Was anderes als eine Reinstall und ein Sicherheitskonzept hilft wohl nicht mehr.

Das Sicherheitskonzept werde ich so bald wie möglich ausarbeiten. Eventuell auch Expertenrat heranziehen.

Mal sehen, wies weitergeht.

Tja, was soll ich sagen? Der erste Hack auf einen meiner Server, der Durchschlagskraft hatte. Zugemüllte Ordner und stetig wechselnde Hostkeys.

Nun gut, was hatte ich schon für Hack-Angriffe in meiner "Karriere"?

DDoS (zwar kein Hack, aber immerhin ein Angriff)
SQL-Injections (gott sei dank die meisten davon total misslungen)
Exploits

So macht man eben seine Erfahrung...was solls...ich stehe wieder auf, reinstalle und mache weiter und verbessere meine Sicherheit...:o
 
Meist ist es noch ganz interessant rauszufinden, wie eingebrochen wurde... mich würde es jedenfalls interessieren, da ich plane, auf eine ähnliche Konfiguration umzustellen (nginx, php5-fpm, mysql, sshd).

Gruß
barni
 
Die Frage hatte sich ja schon weitestgehend geklärt. Durch eine MitM-Attacke das Passwort an einen falschen Server weitergegeben, da die Warnung des geänderten Host-Keys ja ignoriert wurde.
 
Back
Top