Komme nicht mehr per SSH auf Strato-vServer

Koopz

Koopz

New Member
Aloha,

Ich komme seit einigen Tagen nicht mehr per SSH auf meinen vServer.
Wenn ich eine Verbindung zum vServer aufbaue, werde ich nach dem Benutzernamen gefragt. Danach kommt wie gehabt die Frage nach dem Passwort. Nun kann ich so viele Falscheingaben machen, wie ich möchte, Ich bekomme immer "Access Denied" zurück. Wenn ich nun aber das das richtige Passwort eingebe, schließt sich mein PuTTY direkt und sagt "Server unexpextedly closed network connection"

Folgende Ausgabe bekomme ich, wenn ich von einer anderen Maschine aus per ssh -v auf meinen Server verbinde:
Code: 
ssh -v test.de
OpenSSH_5.3p1 Debian-3ubuntu7.1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to test.de [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'test.de' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:13
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
root@test.de's password:
Connection closed by xx.xx.xx.xx

Bei Strato ist es möglich, den vServer in den Recovery Modus zu bringen und das gesamte System in einer anderen Maschine zu mounten.

Ich habe es mit dem root- und einem normalen Benutzer versucht, in beiden Fällen das selbe Verhalten.

Was ich bisher geprüft habe:
  • Rechte auf das /etc/ssh-Verzeichnis geprüft
  • /etc/ssh/sshd_config und /etc/ssh/ssh_config mit den Configs des Recovery-Systems abgeglichen und sichergestellt, dass PermitRootLogin auf "yes" steht.
  • In der /etc/passwd sichergestellt, dass für den Benutzer eine Shell hinterlegt ist.
  • Geprüft, ob im Plesk Panel im Firewall-Plugin eingehende SSH-Verbindungen zugelassen werden.
  • /var/log/auth.log gibt keine Auskunft über eingehende Verbindungen

Meine Vermutung ist, dass sich durch eines der automatischen Updates des Plesk Panels irgendwas zerschossen hat. Leider bin ich nur so langsam mit meinem Latein am Ende und weiß nicht weiter.

Habt ihr noch Ideen, woran es liegen könnte oder sollte ich mich langsam auf eine Neuinstallation des Servers einstellen?

mfg Koopz
 
Wenn in /var/log/auth.log keine Einträge hinzukommen, vielleicht ist das Dateisystem voll?

Findest Du in den anderen Logfiles irgendwelche Hinweise?
 
Also neue Einträge kommen schon ins auth.log, allerdings kommen die von nem Cron.
Und im Plesk wird mir angezeigt, dass ich noch über 46 GB frei habe.
Das Neustarten des Systems hat logischerweise nicht funktioniert, da ich den Server mittlerweile einige Male über die Strato-Oberfläche in den Recovery-Modus und wieder normal gebootet habe.
 
Mal eine blöde Idee: proc & dev mounten, ins normale System chroot'en, den SSH-Daemon mit allen Debug-Ausgaben starten (eventuell anderer Port!) und den Verbindungsversuch von extern nochmals anstoßen. Vielleicht sieht man dann die Ursache ;)

Oder als Alternative im Chroot einen zweiten SSH-Server auf einem anderen Port installieren, schauen ob der dann im normalem Modus funktioniert und so das Problem direkt ohne Recovery-Modus debuggen.


MfG Christian
 
Was ist denn als Shell für den Root-Benutzer hinterlegt?
Kann in der /etc/passwd nachgesehen werden.
 
@gurke: /bin/bash

@killerbees:
Also im Recovery-Modus liegt das System unter /repair.
Heißt, ich soll /proc und /dev nach /repair/proc und /repair/dev mounten und danach "chroot /repair /repair/etc/init.d/ssh start" ausführen, nachdem ich in der /repair/etc/ssh/sshd_config den Port geändert hab?

Hab noch nie mit chroot gearbeitet...

Spiele auch langsam mit dem Gedanken, ein Plesk Backup zu machen, die Kiste neuzuinstallieren und das Backup wieder einzuspielen.

Edit: Habe letzendlich dann doch das Plesk Backup gemacht, den Server neuinstallieren lassen und das Backup wieder eingespielt.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top