ssh-login auf vServer geht nicht mehr

[dermichi]

Hallo Experten,

Ich habe ganz frisch einen vserver bei server4you.

Als erstes habe ich einen User angelegt, root-login verboten und den ssh-Port von 22 auf einen anderen geändert. Das hat soweit funktioniert. Allerdings habe ich dann festgestellt, dass ich auf dem anderen Port nicht über den Firewall komme, hinter dem ich sitze, und ganz unbedacht meinen Server neu gestartet (über das control-Interface).
Das war natürlich dumm, weil ich mich dann nicht merh einloggen konnte, also habe ich den Server neu installiert (ebenfalls über das control-Interface), und seitdem geht überhaupt kein Login mehr.

Ich hab's von verschiedenen Computern hinter der Firewall probiert, bei allen ist die Fehlermeldung folgende:
michi@michi-laptop:~$ ssh root@xx.xx.xxx.xxx
Connection closed by xx.xx.xxx.xxx

bzw.
michi@michi-laptop:~$ ssh -vv root@xx.xx.xxx.xxx

penSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/michi/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xxx.xxx [xx.xx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/michi/.ssh/identity type -1
debug1: identity file /home/michi/.ssh/id_rsa type -1
debug1: identity file /home/michi/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.6
debug1: match: OpenSSH_4.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by xx.xx.xxx.xxx

Jetzt bin ich ziemlich ratlos..
Ich habe den Verdacht, dass es an der Firewall liegt- aber eine Stunde vorher ging's ja auch noch. Von meinem Computer auf andere hinter der FW kann ich mich noch einloggen..
Google konnte mir nicht weiterhelfen.
Hat irgendjemand eine Idee?

edit:
der Port ist natürlich offen.
Ausgabe von nmap:

Starting Nmap 4.53 ( http://insecure.org ) at 2008-08-28 15:13 CEST
Interesting ports on vs242121.vserver.de (xx.xx.xxx.xxx):
Not shown: 1688 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
23/tcp    open  telnet
25/tcp    open  smtp
110/tcp   open  pop3
119/tcp   open  nntp
143/tcp   open  imap
161/tcp   open  snmp
554/tcp   open  rtsp
993/tcp   open  imaps
1404/tcp  open  igi-lm
1433/tcp  open  ms-sql-s
1494/tcp  open  citrix-ica
1501/tcp  open  sas-3
1521/tcp  open  oracle
2401/tcp  open  cvspserver
3000/tcp  open  ppp
3306/tcp  open  mysql
3389/tcp  open  ms-term-serv
4000/tcp  open  remoteanything
4444/tcp  open  krb524
5003/tcp  open  filemaker
5900/tcp  open  vnc
8080/tcp  open  http-proxy
8443/tcp  open  https-alt
27004/tcp open  flexlm4

 

[wstuermer]

Hi,

es fehlt eine entscheidende Angabe. Servernummer?


-W

 

[Daila]

vs242121.vserver.de

Steht im nmap Log.

Ich komm bis zur Passwortabfrage durch.

 

[filewalker]

Interesting ports on vs242121.vserver.de (xx.xx.xxx.xxx):

22/tcp    open  ssh

Ein

telnet vs242121.vserver.de 22

spuckt

SSH-2.0-OpenSSH_4.3p2 Debian-9etch2

aus. D.h., dass der SSH-Demon noch läuft und eine TCP-Verbindung aufbaut.
Ein Firewall-Problem scheidet also aus. Versuch einmal über die Verwaltungsoberfläche Deines Hosters das root-Passwort zurückzusetzen.

 

[wstuermer]

Hi,

ich trau dem nmap nicht, da der zuviele Ports offen hat (SSH + RDP? RDP auf Linux?)
Sollte es der 242121 sein, dann ist dort nur der Port 22 offen.

root@vs242121:/# netstat -atnpl
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     22064/sshd

-W

 

[dermichi]

Erstmal vielen Dank für die Antworten!

Ja, die Servernummer ist 242121, da habt ihr recht.
Ich weiß nicht, ob es was bringt, das root-Password zurückzusetzen - ich komm ja nicht mal bis zur Passworteingabe. Und der ssh-Daemon läuft, das sieht man ja auch an dem Debug-output von ssh. Es gibt anscheinend Schwierigkeiten beim Schlüsselaustausch.

Aber ich probiers trotzdem mal. Leider hab ich im Moment keinen Internetzugang von zu Hause, deswegen muss ich das von hier hinter der Firewall machen.

Ich halte Euch auf dem laufenden!

Edit:
Ich habe noch das gleiche Problem wie gestern... Ab Montag kann ich das von zu Hause aus machen, ich vermute eigentlich, dass der Grund die Firewall hier ist. (Na gut, so komm ich wenigstens zum Arbeiten... :/ =
Ach ja, und ich hoffe, dass wstuermer von s4y ist...Ist das so?

Viele Grüße,

Michi

 

[l0rd]

Hi,

ja wstuermer ist von s4y.

Zu deinem Problem:

... also habe ich den Server neu installiert ...

Bei einer Neuinstallation werden die Schlüssel neugeneriert (soweit ich weiß). Hast du mal den Cache von deinem SSH Client gelöscht? Unter Linux ist dieser unter "~/.ssh/known_hosts " zu finden. Es könnte sein, dass dein Client den Connect verbietet, weil der SSH-Server aus Sicht des Clients möglicherweiße korrumpiert ist.

Das passt zwar nicht ganz zu der Fehlermeldung, weil der Client dies normalerweise mitteilt, aber ein Versuch wäre es wert.

Dennis

 

[blupp1]

Normal sperrt doch die Firewall auf der Arbeit den Port 22?

 

[Daila]

Normal sperrt doch die Firewall auf der Arbeit den Port 22?

Ich glaube das kommt aufs Unternehmen an, bei einem Hoster wäre der Port bestimmt offen wobei er bei einem Getränkehersteller zu wäre.

 

[Firewire2002]

Normal sperrt doch die Firewall auf der Arbeit den Port 22?

Sollt ich meinem Chef mal vorschlagen.
Hmm obwohl, dann wär ich arbeitslos. Nee nee, der bleibt mal schön offen.

Back to Topic:
SSH ist ohne Probleme erreichbar.

 

[dermichi]

Ob der Port offen ist oder nicht, ist immer ein bisschen undurchsichtig.
Manchmal ist er offen.... (ich bin in einem Universitätsklinikum, quasi irgendwas zwischen Getränkemarkt und Hoster). Der Port ist wohl irgendwie offen, weil ich meinen server ja erreiche, aber dann macht er scheints zu.
Aber man kann ja schlecht zu den EDV-Leuten gehen und sagen, sie sollen ihn aufmachen, weil man seinen privaten Server verwalten will...

An sich hat sich's aber erledigt, weil ich ab heute abend wieder daheim online bin, von da sollte es dann ja gehen.

(known_hosts hab ich zwischenzeitlich auch mal gelöscht, das hat aber nichts gebracht)

Vielen Dank für Eure Hilfe, jedenfalls.

 

[dermichi]

Erledigt...

So, von außerhalb der Firewall ist das überhaupt kein Problem.
Inzwischen habe ich auch herausgefunden, was nicht funktioniert hat:

Wir haben hier offensichtliech einen ssh-Proxy, auf dem der Schlüssel von dem externen Server bei der ersten Anmeldung hinterlegt wird. Wenn sich der Schlüssel dann aber ändert, dann gehts nicht mehr. Und man müsste dann bei der EDV anrufen und den Schlüssel löschen lassen. Das ist ja auch sinnvoll, an sich, nur in meinem Fall ärgerlich.

Jedenfalls ist jetzt alles erledigt.