Plötzlich Seltsames Login Verhalten

[boiler]

Hallo,

ich hab schon seit Jahren einen OpenSuse Server laufen, der hauptsächlich als SVN Server läuft. Zuletzt habe ich den Server vor ca. 5 Monaten geupdated

Linux fry 2.6.25.20-0.7-default #1 SMP 2010-02-26 20:32:57 +0100 x86_64 x86_64 x86_64 GNU/Linux

Alles ohne Probleme.

Letzte Woche ist mir aufgefallen das ich öfters per DenyHost ausgesperrt werden, kein Problem IP wechseln und weiter arbeiten. Seit heute morgen kann ich nichts mehr einchecken. Ich arbeite Hauptsächlich von Windows mit SVN, Pageant und TortoiseSVN. Einloggen geht ausschliesslich mit dem Public Key verfahren. Mit Putty kann ich mich einloggen, per SVN einchecken geht nicht, die Verbindung wird nach ewigkeiten geschlossen.
Ich hab als erstes einen Blick in /var/log/messages geworfen, da ist mir aufgefallen das der Login zuerst Fehlschlägt, dann doch aber klappt. Ich weiss nicht ob dass das Problem ist, vermute es aber. Hier ein Auszug aus der Datei:

Sep 14 13:03:48 server sshd[28734]: debug3: fd 4 is not O_NONBLOCK
Sep 14 13:03:48 server sshd[28734]: debug1: Forked child 28739.
Sep 14 13:03:48 server sshd[28734]: debug3: send_rexec_state: entering fd = 7 config len 525
Sep 14 13:03:48 server sshd[28734]: debug3: ssh_msg_send: type 0
Sep 14 13:03:48 server sshd[28734]: debug3: send_rexec_state: done
Sep 14 13:03:48 server sshd[28739]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
Sep 14 13:03:48 server sshd[28739]: debug1: inetd sockets after dupping: 3, 3
Sep 14 13:03:48 server sshd[28739]: Connection from 93.194.92.218 port 51408
Sep 14 13:03:48 server sshd[28739]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
Sep 14 13:03:48 server sshd[28739]: debug1: no match: PuTTY_Release_0.60
Sep 14 13:03:48 server sshd[28739]: debug1: Enabling compatibility mode for protocol 2.0
Sep 14 13:03:48 server sshd[28739]: debug1: Local version string SSH-2.0-OpenSSH_5.0
Sep 14 13:03:48 server sshd[28739]: debug2: fd 3 setting O_NONBLOCK
Sep 14 13:03:48 server sshd[28739]: debug2: Network child is on pid 28743
Sep 14 13:03:48 server sshd[28739]: debug3: preauth child monitor started
Sep 14 13:03:48 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:48 server sshd[28739]: debug3: monitor_read: checking request 0
Sep 14 13:03:48 server sshd[28739]: debug3: mm_answer_moduli: got parameters: 1024 4096 8192
Sep 14 13:03:48 server sshd[28739]: debug3: mm_request_send entering: type 1
Sep 14 13:03:48 server sshd[28739]: debug2: monitor_read: 0 used once, disabling now
Sep 14 13:03:48 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:48 server sshd[28739]: debug3: monitor_read: checking request 4
Sep 14 13:03:48 server sshd[28739]: debug3: mm_answer_sign
Sep 14 13:03:48 server sshd[28739]: debug3: mm_answer_sign: signature 0x7f36b91ee910(143)
Sep 14 13:03:48 server sshd[28739]: debug3: mm_request_send entering: type 5
Sep 14 13:03:48 server sshd[28739]: debug2: monitor_read: 4 used once, disabling now
Sep 14 13:03:48 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:52 server sshd[28739]: debug3: monitor_read: checking request 6
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_pwnamallow
Sep 14 13:03:52 server sshd[28739]: debug3: Trying to reverse map address 93.194.92.218.
Sep 14 13:03:52 server sshd[28739]: debug2: parse_server_config: config reprocess config len 525
Sep 14 13:03:52 server sshd[28739]: debug3: auth_shadow_acctexpired: today 15231 sp_expire -1 days left -15232
Sep 14 13:03:52 server sshd[28739]: debug3: account expiration disabled
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
Sep 14 13:03:52 server sshd[28739]: debug3: mm_request_send entering: type 7
Sep 14 13:03:52 server sshd[28739]: debug2: monitor_read: 6 used once, disabling now
Sep 14 13:03:52 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:52 server sshd[28739]: debug3: monitor_read: checking request 3
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_authserv: service=ssh-connection, style=
Sep 14 13:03:52 server sshd[28739]: debug2: monitor_read: 3 used once, disabling now
Sep 14 13:03:52 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:52 server sshd[28739]: debug3: monitor_read: checking request 20
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_keyallowed entering
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_keyallowed: key_from_blob: 0xee6b96b037f1
Sep 14 13:03:52 server sshd[28739]: debug1: temporarily_use_uid: 1000/100 (e=0/0)
Sep 14 13:03:52 server sshd[28739]: debug1: trying public key file /home/boiler/.ssh/authorized_keys
Sep 14 13:03:52 server sshd[28739]: debug1: restore_uid: 0/0
Sep 14 13:03:52 server sshd[28739]: debug1: temporarily_use_uid: 1000/100 (e=0/0)
Sep 14 13:03:52 server sshd[28739]: debug1: trying public key file /home/boiler/.ssh/authorized_keys2
Sep 14 13:03:52 server sshd[28739]: debug3: secure_filename: checking '/home/boiler/.ssh'
Sep 14 13:03:52 server sshd[28739]: debug3: secure_filename: checking '/home/boiler'
Sep 14 13:03:52 server sshd[28739]: debug3: secure_filename: terminating check at '/home/boiler'
Sep 14 13:03:52 server sshd[28739]: debug1: restore_uid: 0/0
Sep 14 13:03:52 server sshd[28739]: debug2: key not found
Sep 14 13:03:52 server sshd[28739]: Failed publickey for boiler from 93.194.92.218 port 51408 ssh2
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_keyallowed: key 0xee6b96b037f1 is disallowed
Sep 14 13:03:52 server sshd[28739]: debug3: mm_request_send entering: type 21
Sep 14 13:03:52 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:52 server sshd[28739]: debug3: monitor_read: checking request 20
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_keyallowed entering
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_keyallowed: key_from_blob: 0xee6b96b037f1
Sep 14 13:03:52 server sshd[28739]: debug1: temporarily_use_uid: 1000/100 (e=0/0)
Sep 14 13:03:52 server sshd[28739]: debug1: trying public key file /home/boiler/.ssh/authorized_keys
Sep 14 13:03:52 server sshd[28739]: debug1: restore_uid: 0/0
Sep 14 13:03:52 server sshd[28739]: debug1: temporarily_use_uid: 1000/100 (e=0/0)
Sep 14 13:03:52 server sshd[28739]: debug1: trying public key file /home/boiler/.ssh/authorized_keys2
Sep 14 13:03:52 server sshd[28739]: debug3: secure_filename: checking '/home/boiler/.ssh'
Sep 14 13:03:52 server sshd[28739]: debug3: secure_filename: checking '/home/boiler'
Sep 14 13:03:52 server sshd[28739]: debug3: secure_filename: terminating check at '/home/boiler'
Sep 14 13:03:52 server sshd[28739]: debug1: restore_uid: 0/0
Sep 14 13:03:52 server sshd[28739]: debug2: key not found
Sep 14 13:03:52 server sshd[28739]: Failed publickey for boiler from 93.194.92.218 port 51408 ssh2
Sep 14 13:03:52 server sshd[28739]: debug3: mm_answer_keyallowed: key 0xee6b96b037f1 is disallowed
Sep 14 13:03:52 server sshd[28739]: debug3: mm_request_send entering: type 21
Sep 14 13:03:52 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:53 server sshd[28739]: debug3: monitor_read: checking request 20
Sep 14 13:03:53 server sshd[28739]: debug3: mm_answer_keyallowed entering
Sep 14 13:03:53 server sshd[28739]: debug3: mm_answer_keyallowed: key_from_blob: 0xee6b96b037f1
Sep 14 13:03:53 server sshd[28739]: debug1: temporarily_use_uid: 1000/100 (e=0/0)
Sep 14 13:03:53 server sshd[28739]: debug1: trying public key file /home/boiler/.ssh/authorized_keys
Sep 14 13:03:53 server sshd[28739]: debug1: restore_uid: 0/0
Sep 14 13:03:53 server sshd[28739]: debug1: temporarily_use_uid: 1000/100 (e=0/0)
Sep 14 13:03:53 server sshd[28739]: debug1: trying public key file /home/boiler/.ssh/authorized_keys2
Sep 14 13:03:53 server sshd[28739]: debug3: secure_filename: checking '/home/boiler/.ssh'
Sep 14 13:03:53 server sshd[28739]: debug3: secure_filename: checking '/home/boiler'
Sep 14 13:03:53 server sshd[28739]: debug3: secure_filename: terminating check at '/home/boiler'
Sep 14 13:03:53 server sshd[28739]: debug1: matching key found: file /home/boiler/.ssh/authorized_keys2, line 1
Sep 14 13:03:53 server sshd[28739]: Found matching RSA key: blablub
Sep 14 13:03:53 server sshd[28739]: debug1: restore_uid: 0/0
Sep 14 13:03:53 server sshd[28739]: debug3: mm_answer_keyallowed: key 0xee6b96b037f1 is allowed
Sep 14 13:03:53 server sshd[28739]: debug3: mm_request_send entering: type 21
Sep 14 13:03:53 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:54 server sshd[28739]: debug3: monitor_read: checking request 20
Sep 14 13:03:54 server sshd[28739]: debug3: mm_answer_keyallowed entering
Sep 14 13:03:54 server sshd[28739]: debug3: mm_answer_keyallowed: key_from_blob: 0x7f36b91ee6f0
Sep 14 13:03:54 server sshd[28739]: debug1: temporarily_use_uid: 1000/100 (e=0/0)
Sep 14 13:03:54 server sshd[28739]: debug1: trying public key file /home/boiler/.ssh/authorized_keys
Sep 14 13:03:54 server sshd[28739]: debug1: restore_uid: 0/0
Sep 14 13:03:54 server sshd[28739]: debug1: temporarily_use_uid: 1000/100 (e=0/0)
Sep 14 13:03:54 server sshd[28739]: debug1: trying public key file /home/boiler/.ssh/authorized_keys2
Sep 14 13:03:54 server sshd[28739]: debug3: secure_filename: checking '/home/boiler/.ssh'
Sep 14 13:03:54 server sshd[28739]: debug3: secure_filename: checking '/home/boiler'
Sep 14 13:03:54 server sshd[28739]: debug3: secure_filename: terminating check at '/home/boiler'
Sep 14 13:03:54 server sshd[28739]: debug1: matching key found: file /home/boiler/.ssh/authorized_keys2, line 1
Sep 14 13:03:54 server sshd[28739]: Found matching RSA key: blablub
Sep 14 13:03:54 server sshd[28739]: debug1: restore_uid: 0/0
Sep 14 13:03:54 server sshd[28739]: debug3: mm_answer_keyallowed: key 0x7f36b91ee6f0 is allowed
Sep 14 13:03:54 server sshd[28739]: debug3: mm_request_send entering: type 21
Sep 14 13:03:54 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:54 server sshd[28739]: debug3: monitor_read: checking request 22
Sep 14 13:03:54 server sshd[28739]: debug1: ssh_rsa_verify: signature correct
Sep 14 13:03:54 server sshd[28739]: debug3: mm_answer_keyverify: key 0x7f36b91ee670 signature verified
Sep 14 13:03:54 server sshd[28739]: debug3: mm_request_send entering: type 23
Sep 14 13:03:54 server sshd[28739]: Accepted publickey for boiler from 93.194.92.218 port 51408 ssh2
Sep 14 13:03:54 server sshd[28739]: debug1: monitor_child_preauth: boiler has been authenticated by privileged process
Sep 14 13:03:54 server sshd[28739]: debug3: mm_get_keystate: Waiting for new keys
Sep 14 13:03:54 server sshd[28739]: debug3: mm_request_receive_expect entering: type 24
Sep 14 13:03:54 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:54 server sshd[28739]: debug3: mm_newkeys_from_blob: 0x7f36b91f01e0(143)
Sep 14 13:03:54 server sshd[28739]: debug2: mac_setup: found hmac-sha1
Sep 14 13:03:54 server sshd[28739]: debug3: mm_get_keystate: Waiting for second key
Sep 14 13:03:54 server sshd[28739]: debug3: mm_newkeys_from_blob: 0x7f36b91f01e0(143)
Sep 14 13:03:54 server sshd[28739]: debug2: mac_setup: found hmac-sha1
Sep 14 13:03:54 server sshd[28739]: debug3: mm_get_keystate: Getting compression state
Sep 14 13:03:54 server sshd[28739]: debug3: mm_get_keystate: Getting Network I/O buffers
Sep 14 13:03:54 server sshd[28739]: debug3: mm_share_sync: Share sync
Sep 14 13:03:54 server sshd[28739]: debug3: mm_share_sync: Share sync end
Sep 14 13:03:54 server sshd[28739]: debug2: User child is on pid 28744
Sep 14 13:03:54 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:54 server sshd[28744]: debug1: permanently_set_uid: 1000/100
Sep 14 13:03:54 server sshd[28744]: debug2: set_newkeys: mode 0
Sep 14 13:03:54 server sshd[28744]: debug2: cipher_init: set keylen (16 -> 32)
Sep 14 13:03:54 server sshd[28744]: debug2: set_newkeys: mode 1
Sep 14 13:03:54 server sshd[28744]: debug2: cipher_init: set keylen (16 -> 32)
Sep 14 13:03:54 server sshd[28744]: debug1: Entering interactive session for SSH2.
Sep 14 13:03:54 server sshd[28744]: debug2: fd 5 setting O_NONBLOCK
Sep 14 13:03:54 server sshd[28744]: debug2: fd 6 setting O_NONBLOCK
Sep 14 13:03:54 server sshd[28744]: debug1: server_init_dispatch_20
Sep 14 13:03:54 server sshd[28744]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Sep 14 13:03:54 server sshd[28744]: debug1: input_session_request
Sep 14 13:03:54 server sshd[28744]: debug1: channel 0: new [server-session]
Sep 14 13:03:54 server sshd[28744]: debug1: session_new: init
Sep 14 13:03:54 server sshd[28744]: debug1: session_new: session 0
Sep 14 13:03:54 server sshd[28744]: debug1: session_open: channel 0
Sep 14 13:03:54 server sshd[28744]: debug1: session_open: session 0: link with channel 0
Sep 14 13:03:54 server sshd[28744]: debug1: server_input_channel_open: confirm session
Sep 14 13:03:55 server sshd[28744]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Sep 14 13:03:55 server sshd[28744]: debug1: session_by_channel: session 0 channel 0
Sep 14 13:03:55 server sshd[28744]: debug1: session_input_channel_req: session 0 req pty-req
Sep 14 13:03:55 server sshd[28744]: debug1: Allocating pty.
Sep 14 13:03:55 server sshd[28744]: debug3: mm_request_send entering: type 25
Sep 14 13:03:55 server sshd[28739]: debug3: monitor_read: checking request 25
Sep 14 13:03:55 server sshd[28739]: debug3: mm_answer_pty entering
Sep 14 13:03:55 server sshd[28739]: debug1: session_new: init
Sep 14 13:03:55 server sshd[28739]: debug1: session_new: session 0
Sep 14 13:03:55 server sshd[28739]: debug3: mm_request_send entering: type 26
Sep 14 13:03:55 server sshd[28739]: debug3: mm_answer_pty: tty /dev/pts/1 ptyfd 4
Sep 14 13:03:55 server sshd[28739]: debug3: mm_request_receive entering
Sep 14 13:03:55 server sshd[28744]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY
Sep 14 13:03:55 server sshd[28744]: debug3: mm_request_receive_expect entering: type 26
Sep 14 13:03:55 server sshd[28744]: debug3: mm_request_receive entering
Sep 14 13:03:55 server sshd[28744]: debug1: session_pty_req: session 0 alloc /dev/pts/1
Sep 14 13:03:55 server sshd[28744]: debug3: tty_parse_modes: SSH2 n_bytes 16
Sep 14 13:03:55 server sshd[28744]: debug3: tty_parse_modes: 3 127
Sep 14 13:03:55 server sshd[28744]: debug3: tty_parse_modes: ispeed 38400
Sep 14 13:03:55 server sshd[28744]: debug3: tty_parse_modes: ospeed 38400
Sep 14 13:03:55 server sshd[28744]: debug1: server_input_channel_req: channel 0 request shell reply 1
Sep 14 13:03:55 server sshd[28744]: debug1: session_by_channel: session 0 channel 0
Sep 14 13:03:55 server sshd[28744]: debug1: session_input_channel_req: session 0 req shell
Sep 14 13:03:55 server sshd[28744]: debug2: fd 3 setting TCP_NODELAY
Sep 14 13:03:55 server sshd[28744]: debug2: channel 0: rfd 8 isatty
Sep 14 13:03:55 server sshd[28745]: debug1: Setting controlling tty using TIOCSCTTY.
Sep 14 13:03:55 server sshd[28744]: debug2: fd 8 setting O_NONBLOCK
Sep 14 13:03:55 server sshd[28744]: debug3: fd 7 is O_NONBLOCK
Sep 14 13:03:55 server sshd[28745]: debug3: channel 0: close_fds r -1 w -1 e -1 c -1

Hat jemand eine Idee? Bin im Moment relativ Ratlos wonach ich suchen soll...

Gruß Mario

 

[spoensche]

ich hab schon seit Jahren einen OpenSuse Server laufen, der hauptsächlich als SVN Server läuft. Zuletzt habe ich den Server vor ca. 5 Monaten geupdated
Linux fry 2.6.25.20-0.7-default #1 SMP 2010-02-26 20:32:57 +0100 x86_64 x86_64 x86_64 GNU/Linux

Der Kernelversion nach werkelt bei dir eine Susi 11.0 oder? Wenn ja, dann frage ich mich wie du ein Update gemacht hast, weil es für 11.0 seit 2010 keinerlei Updates mehr gibt.

Sicherheitsupdate installiert man auch nicht alle 5.Monate mal. Das Verhalten ist mit grob Fahrlässig noch untertrieben.

Mal abgesehen davon schlägt die Pubkey Anmeldungen nicht beim ersten Versuch fehl und funktioniert beim zweiten mal. Ganz zu schweigen von Schlüsseln, die plötzlich disallowed sind.

 

[boiler]

Bleib bitte Problemorientiert, alter Kernel und Updateintervalle stehen hier nicht zur Diskussion - Danke. Deine Antwort kann ich nicht verstehen, meine Frage ist hoffentlich klar und ich habe genug Informationen gegeben sodass man Antworten kann. Du beschreibst leider nur was du im Logfile siehst, schliesst aber daraus keinen Schluss. :-(

 

[Feuervogel]

Bleib bitte Problemorientiert, alter Kernel und Updateintervalle stehen hier nicht zur Diskussion - Danke. ...

Hallo boiler,

ich denke, dass spoensches Hinweis darauf in diesem Faden - Teilforum: "Security & Backup" - sehr wohl angebracht ist.

Gruß
Feuervogel

 

[spoensche]

Bleib bitte Problemorientiert, alter Kernel und Updateintervalle stehen hier nicht zur Diskussion - Danke. Deine Antwort kann ich nicht verstehen, meine Frage ist hoffentlich klar und ich habe genug Informationen gegeben sodass man Antworten kann.

Das ist problemorientiert, weil du Angreifern freiwillig Möglichkeiten bietest dein System erfolgreich anzugreifen.

Du beschreibst leider nur was du im Logfile siehst, schliesst aber daraus keinen Schluss. :-(

Das sind Anomalien und dein Server, mangels Sicherheitsvorkehrungen und Updates, mit großer Wahrscheinlichkeit kompromitiert (übernommen) worden ist. D.h. den Server vom Netz nehmen, nach Spuren und Ursachen suchen etc. und komplett neu aufsetzen ink. Sicherheitsvorkehrungen, wie z.B. Firewall, regelmäßige Updates, tägliche Kontrolle der Logfiles etc.

 

[boiler]

@Feuervogel
Gut, es passt für dieses Unterforum, aber die Antwort ist reflexartig und mit einem unterschwelligem Ton der der letzte Antwort von spoensche entspricht. Leider ist diese Art in vielen Foren typisch, vor allem wenn es um Computer geht und dann nochmal mehr wenn Linux im Spiel ist

@spoensche
Danke für deine Antwort auch wenn du denkst das ich keine Sicherheitsvorgekehrungen treffe Das Problem mit dem Abbruch ist gelöst, das DSL Modem hat nach 3 Jahren Dauerbetrieb den Geist aufgegeben. Für mich sind das alles bisher keine Zeichen einer Kompromitierung.

Das zweite Problem das ein Login von Usern in /var/log/messages als "Failed publickey for" gemeldet wird, dann aber doch klappt "Found matching RSA key" bleibt noch. Interessanterweisse trifft das nicht für den root User zu. Hat da noch jemand eine Idee? Wenn nicht einer meiner Sicherheitsvorgekehrungen mir dauernt Mails deswegen schicken würde, wäre es mir egal. Ich versuche parallel die Tage selbst eine Lösung zu finden....

 

[Rainer Juhser]

@Feuervogel
Gut, es passt für dieses Unterforum, aber die Antwort ist reflexartig und mit einem unterschwelligem Ton der der letzte Antwort von spoensche entspricht. Leider ist diese Art in vielen Foren typisch, vor allem wenn es um Computer geht und dann nochmal mehr wenn Linux im Spiel ist

Und das hat auch seinen Grund...

 

[framp]

...Gut, es passt für dieses Unterforum, aber die Antwort ist reflexartig und mit einem unterschwelligem Ton der der letzte Antwort von spoensche entspricht. Leider ist diese Art in vielen Foren typisch, vor allem wenn es um Computer geht und dann nochmal mehr wenn Linux im Spiel ist

Daraus lese ich dass Du schlechte Erfahrungen in Linuxforen gemacht hast. Das gefällt mir nicht und ich möchte das genauer verstehen. Um mir ein Bild zu machen:
1) Welche Foren waren das?
2) Kannst Du konkrete Threads mit URLs nennen wo Du schlechte Erfahrungen gemacht hast?

 

[spoensche]

@spoensche
Danke für deine Antwort auch wenn du denkst das ich keine Sicherheitsvorgekehrungen treffe Das Problem mit dem Abbruch ist gelöst, das DSL Modem hat nach 3 Jahren Dauerbetrieb den Geist aufgegeben. Für mich sind das alles bisher keine Zeichen einer Kompromitierung.

Ich habe nicht gesagt, dass du keine Sicherheitsvorkehrungen getroffen hast. Mein Hinweis auf Kompromitierung bezieht sich auch auf Publickey Anomalie.

Aber Fakt ist: Server am Internet = Distribution, die mit aktuellen Sicherheitsupdates versorgt wird und nicht EOL ist. (Grundvoraussetzung)

Das zweite Problem das ein Login von Usern in /var/log/messages als "Failed publickey for" gemeldet wird, dann aber doch klappt "Found matching RSA key" bleibt noch. Interessanterweisse trifft das nicht für den root User zu.

Als User root meldet man sich nicht per SSH an, weder mit PublicKey noch mit Passwort. (PermitRootLogin no in sshd_config)

Hat da noch jemand eine Idee? Wenn nicht einer meiner Sicherheitsvorgekehrungen mir dauernt Mails deswegen schicken würde, wäre es mir egal. Ich versuche parallel die Tage selbst eine Lösung zu finden....

:schockiert:
Was glaubst du wohl, warum du diese Mails bekommst??? Dir kann es doch nicht egal sein, dass dein Server kompromitiert worden ist. Schon mal davon gehört das man auch als normaler User Root-Rechte erlangen kann??
Also wenn dir eine Kompromitierung egal ist, dann solltest du allen einen Gefallen tun und den Server vom Netz und niemals wieder einen ans Netz hängen.
Es gibt schon genug Rechner in Botnetzen und auch genug Rechner die als Spamschleuder arbeiten und/oder für Angriffe verwendet werden.

PS:
Wenn dein Server für Angriffe missbraucht wird und raus kommt, dass du als Verantwortlicher des Servers fahrlässig mit der Absicherung etc. umgegangen bist können Schadensersatzforderungen gegen dich geltend gemacht werden, zusätzlich hohe Geldstrafen oder Gefängnistrafen verhängt werden.