virtual Server mit ssh verbinden

[realheat]

Hallo,

ich habe von 1und1 ein virtual-Server mit Ubuntu 8.04, als ich nach längeren Zeiten mit ssh verbinden wollte, bringt er mir nun folgendes:

Client:~ Benutzer$ ssh -vv root@xx.xxx.xxx.xxOpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xxx.xxx.xx [xx.xxx.xxx.xx] port 22.
debug1: Connection established.
debug1: identity file /Users/Benutzer/.ssh/identity type -1
debug1: identity file /Users/Benutzer/.ssh/id_rsa type 1
debug1: identity file /Users/Benutzer/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

Es scheint so, als würde er meine Authentifizierung mitschicken, aber die hatte ich auf dem Sever noch nicht bekannt gegeben. Der Server fragt schon garnicht nach ein Passwort sondern trennt davor schon die Verbindung.Leider komme ich nun garnicht nicht mehr auf dem Server, kann daher Serverseitig nichts ändern. Habt ihr ein Tipp wie ich weiter kommen kann?
Danke schon mal

Gruß

 

[saeckereier]

Tja, dann soltest du mal schleunigst den Server zurücksetzen lassen, denn er gehört dir längst nicht mehr. Sieht nach gekapert aus. Und dann überlegen, ob es nicht vielleicht sinnvoller wäre nur Webspace oder etwas anderes zu mieten, wo du weniger Verantwortung für die Sicherheit des Servers trägst.

 

[realheat]

sehr freundlich, danke.

 

[saeckereier]

Naja, genau solche Server sind nachher für Spam und DDOS Attacken und was nicht alles verantwortlich. Warum sollte man das gutheißen? Jeder, der dafür qualifiziert ist, einen eigenen Server zu betreiben, sollte diese Eingangsfrage nicht stellen müssen. Auch bei einem Profi kann der Server gekapert werden, der weiß dann aber auch, wie er damit umgeht.

 

[Gast1]

Dieses "nach längerer Zeit mal wieder eingeloggt" impliziert natürlich die Fragen

a) wie lange war diese "längere Zeit"?

b) wer hat in dieser Zeit Sicherheitsupdates eingespielt?

Und da es sich um ein Debianderivat handelt, mal ein wenig Lesestoff, warum SSH in dieser Version unsicher gewesen sein könnte.

http://www.us-cert.gov/cas/techalerts/TA08-137A.html

Sofern die Kiste dagegen nicht gepatcht und dann auch alle Schlüssel ausgetauscht wurden (zumindest sieht der Debugoutput nach key-based authentication aus), wäre das schon mal eine sehr passende Sollbruchstelle.

Nicht daß dies per se der wahrscheinlichste Weg eines Einbruchs allgemein ist, aber bei den Voraussetzungen erhöht sich diese Wahrscheinlichkeit beträchtlich.

 

[realheat]

den Server habe ich vor einem Monat besorgt, leider hatte ich danach keine Zeit mehr ihn einzurichten. Hätte ich gleich gewusst, dass die Leute sich gleich drauf stürzen ...
Habe den Rechner neugestartet und danach konnte ich mich wieder einloggen, danach habe ich sshd_config richtig eingestellt und das System upgegradet.
Ich entschuldige mich, wollte ja kein Monster in die Welt setzen und den Herrn aus dem Norden stören.
@Rain_Maker danke