Fremdzugriff auf meinen Server

[Bryan]

Hallo,

seit drei Tagen versuchen IP-Adressen aus der USA, China und Russland auf meinen Server zu connecten. Da steht dann sowas wie:

Nov 15 17:10:41 xxxx sshd[6710]: Invalid user 89502 from xxx.xx.xxx.xxx
Nov 15 17:10:41 xxxx sshd[6710]: input_userauth_request: invalid user 89502 [preauth]
Nov 15 17:10:41 xxxx sshd[6710]: pam_unix(sshd:auth): check pass; user unknown
Nov 15 17:10:41 xxxx sshd[6710]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xx
Nov 15 17:10:43 xxxx sshd[6710]: Failed password for invalid user 89502 from xxx.xx.xxx.xxx port 18382 ssh2
Nov 15 17:10:43 xxxx sshd[6710]: Connection closed by xxx.xx.xxx.xxx [preauth]
Nov 15 17:12:09 xxxx sshd[6714]: Connection closed by xx.xx.xxx.xx [preauth]
Nov 15 17:14:55 xxxx sshd[6716]: Connection closed by xx.xx.xxx.xx[preauth]

Ich weiß nicht was ich noch machen soll... Ich habe schon das Passwort geändert und und sperre den IP-Bereich immer mit iptables, aber das werden immer mehr???

Ich habe das auch schon mal mit diesen SSH-Keys versucht aber das bekomm ich auch nicht hin...

Kann mit bitte jemand helfen?

MfG
Bryan

[DeletedUserReAsG]

Übliche Workarounds sind fail2ban, oder einfach einen anderen Port zu nehmen. Ansonsten: heutzutage noch mit Passwörtern, also ohne Keys, zu agieren, darf man schon als fahrlässig bezeichnen, und aufgrund einiger Bots gleich ganze IP-Ranges auszuschließen ist … fragwürdig.

[Bryan]

Fail2Ban ist eigentlich da???

Aber komischerweise funktioniert das nicht immer...

Kann mir das jemand mit den SSH-Keys erklären?
Ich steige da nicht ganz durch und habe es jetzt schon das dritte mal versucht...

MfG
Bryan

[sbruder]

Fail2Ban ist eigentlich da???
Kann mir das jemand mit den SSH-Keys erklären?
Ich steige da nicht ganz durch und habe es jetzt schon das dritte mal versucht...

Bei einer Standard-SSH-Installation geht das ganz einfach:

Code: Alles auswählen

ssh-keygen # Auf dem Client

Anweisungen von ssh-keygen befolgen

Code: Alles auswählen

ssh-copy-id user@example.com # Auf dem Client

Dann das Passwort eingeben und der Schlüssel ist auf dem Server

Um Passwortauthentifizierung zu deaktivieren: in die /etc/ssh/sshd_config:

Code: Alles auswählen

PasswordAuthentication no

WICHTIG: sshd danach neustarten und SITZUNG OFFENLASSEN! Falls es Fehler gibt,kommt man sonst nicht mehr aufs System!

[DeletedUserReAsG]

Fail2Ban ist eigentlich da?

Und, ist’s denn auch entsprechend konfiguriert? Ich denke nicht – sonst würd’s diesen Thread nicht geben. Wenn du also auf fail2ban setzen willst, solltest du dich in dessen Bedienung einlesen.

[trg2889]

Poste mal deine /etc/fail2ban/jail.local Ansonsten neuen User anlegen und in der sshd_config allowuser den neuen Benutzer setzen

[MSfree]

seit drei Tagen versuchen IP-Adressen aus der USA, China und Russland auf meinen Server zu connecten.

So etwas läßt sich grundsätzlich nicht verhindern, weil du keine Gewalt über die Rechner hast, die sich mit deiner Kiste zu verbinden versuchen.

Kann mit bitte jemand helfen?

Nein, die Angriffe kann man nicht stoppen. Du kannst nur deinen Server so gut wie möglich absichern, damit es keinem gelingt, sich einzuloggen. Die Verbindungsversuche werden aber bleiben.

Ich habe das auch schon mal mit diesen SSH-Keys versucht aber das bekomm ich auch nicht hin...

Wie es geht, wurde ja schon gepostet. Es kann dich aber nicht gegen Verbindungsversuche schützen.

Solange im Log aber authentication failure steht, ist auch noch nichts gefährliches passiert.

[BenutzerGa4gooPh]

Könnte es sein, dass abgelehnte Autorisierung (nach fehlgeschlagener Authentifizierung) der "best case" ist? Sinn und Zweck jedweder vorbeugenden Maßnahme?! Eben gelesen: MSFree war (wie immer) schneller.

Angriffe können mit ungewöhnlichen (hohen) Ports (wenigstens für Management) verringert werden. Damit schlagen teilweise Script-Automatismen der Angreifer fehl. Alarme im IDS verringern sich. Admins haben wenigstens etwas mehr Ruhe durch IDS-Alarme.

Die Dienste an sich, deren Erreichbarkeit kann man wohl wenig vor DDOS schützen. Manche Firewalls versuchen dies. K. A. ob sie es immer können. Notfalls per IDS erkannte Angreifer, deren IPs mal sperren - bis die sich was anderes einfallen lassen. Der angebotene Dienst bleibt somit frei. Bis zum nächsten (leicht geänderten DDOS-) Mal.
https://de.wikipedia.org/wiki/Denial_of ... d_Botnetze
Manche "Kunden" und deren IP-Netze (IPs nach Lokalitäten/Ländern zugeordnet) braucht eine Firma vlt. nicht unbedingt???
http://www.heise.de/ix/artikel/Spurensuche-506116.html
https://de.wikipedia.org/wiki/Internet_ ... _Authority
Selbst weitersuchen, entscheiden?!

Tja, bis Proxy only habe ich mich selbst noch nicht durchgekämpft, bin aber tapfer dabei.

[Bryan]

Hallo danke für eure ganze Hilfe

Ich werde mich mit euren Tipps mal probieren

Ich habe aber auch einen Verdacht, welches Netzwerk das sein könnte, welche solche Angriffe ausführt... Dazu habe ich gerade ein Video gefunden:

https://www.youtube.com/watch?v=Sw1shJiuTmg

MfG
Bryan

[Alternativende]

Das hier könnte auch einen langen guten Blick Wert sein

https://www.debian.org/doc/manuals/secu ... es.de.html

[DeletedUserReAsG]

Ich habe aber auch einen Verdacht, welches Netzwerk das sein könnte, welche solche Angriffe ausführt...

Das sind stinknormale Bots von anderen aufgemachten Kisten.

[spiralnebelverdreher]

Hallo,

seit drei Tagen versuchen IP-Adressen aus der USA, China und Russland auf meinen Server zu connecten. Da steht dann sowas wie:

Nov 15 17:10:41 xxxx sshd[6710]: Invalid user 89502 from xxx.xx.xxx.xxx
Nov 15 17:10:41 xxxx sshd[6710]: input_userauth_request: invalid user 89502 [preauth]
Nov 15 17:10:41 xxxx sshd[6710]: pam_unix(sshd:auth): check pass; user unknown

Ich weiß nicht was ich noch machen soll... Ich habe schon das Passwort geändert und und sperre den IP-Bereich immer mit iptables, aber das werden immer mehr???
Kann mit bitte jemand helfen?

Hallo und willkommen im Internet!
Was du da beobachtest, ist leider üblich geworden im Internet. Wie andere hier schon geschrieben haben, sind viele schlecht administrierte Rechner weltweit inzwischen mit Schadsoftware infiziert. Das wird mit dem "Internet of things" (oder auch "internet of crap") in Zukunft noch schlimmer werden. Von diesen infizierten Rechnern aus werden Versuche unternommen, sich in andere Rechner einzuloggen um Informationen abzuziehen und/oder Schadsoftware zu installieren.
Die "üblichen" Angriffe suchen nach schwachen Opfern im Netz, zB Rechner mit einem user "root", "student1", "tester" und einem sehr schwachen Passwort ("root123", "123admin", "letmein", "student1" ...). Es werden zig häufige Nutzernamen ausprobiert und an jedem Nutzernamen zig Passwörter. Wenn das nichts fruchtet, knöpft sich der Bot das nächste mögliche Opfer vor.
Gegen diese Angriffe bist du mit einem wirklich starken Passwort derzeit noch relativ gut gefeit. Aber das Spiel geht weiter, die Bots werden erstens mehr und zweitens hartnäckiger und versuchen irgendwann zigtausende Passwörter. Deshalb ist es wichtig, sich schon heute mit einer besseren, schlüsselbasierten Absicherung zu beschäftigen.
Wenn man dieses Konzept mal verstanden hat, ist es mit der Umsetzung erstaunlich leicht.
Andere Maßnahmen wie fail2ban sind nicht falsch und helfen, dass deine Logfiles nicht platzen vor lauter Protokollierung der Einbruchversuche. Sie sind aber verglichen mit einem kryptografisch abgesicherten Zugangsschutz nur die zweite Wahl, da die Angriffe inzwischen über viele IP-Adressen gefahren werden. Und dank Internet-of-crap werden das immer mehr IP-Adressen werden.

"Helfen" kannst du dir nur selbst: Nutze ssh-Schlüssel und deaktiviere den passwortbasierten Zugang. Weitere Maßnahmen wie exotische Portnummern und fail2ban verschlanken heute noch deine Logfiles, sind als alleinige Maßnahme auf Dauer zu schwach.

[MSfree]

Was du da beobachtest, ist leider üblich geworden im Internet.

Das war schon immer so und ist keine neue Entwicklung. Allerdings waren die Bandbreiten im Internet vor 20 Jahren noch ein limitierender Faktor, eine 28kBit/s Modemleitung zu fluten war deutlich einfacher als eine heutige zig MBit dicke DSL-Leitung.

die Bots werden erstens mehr und zweitens hartnäckiger und versuchen irgendwann zigtausende Passwörter.

Gegen reihenweises ausprobieren von sehr vielen Paßwörtern schützt sich Linux aber schon von Haus aus. Einerseits lassen sich mit einerm Verbindungsversuch nur 3 Paßwörter ausprobieren bevor man die nächste
Verbindung aufbauen muß, was wiederum Zeit kostet. Andererseits kann man mit Mechanismen wie fail2ban auch die maximal zulässige Zahl der Verbindungen pro IP-Adresse begrenzen und Zeitintervalle steuern, die bis zum nächsten Versuch vergehen müssen. Dadurch wird es unmöglich, mehr als ein paar hundert Paßwörter pro Tag durchzuprobieren.

Deshalb ist es wichtig, sich schon heute mit einer besseren, schlüsselbasierten Absicherung zu beschäftigen.

Auch Schlüssel sind kein absoluter Schutz. Vor rund 15 Jahren gab es in SSH einen Fehler, der ausgenutzt werden konnten, wenn man nur schlüsselbasierten Zugang eingerichtet hatte. Prompt wurde dann ein von mir administriertes System gehackt. Dabei wurde nicht einmal der Schlüssel gehackt sondern SSH über einen Seitenkanal geknackt. Der Angreifer konnte sich damit am schlüsselbasierten Authetifizierungsmechanismus vorbei schleichen.

"Helfen" kannst du dir nur selbst: Nutze ssh-Schlüssel und deaktiviere den passwortbasierten Zugang.

Das sollte man sowieso immer so einrichten.

Weitere Maßnahmen wie exotische Portnummern und fail2ban verschlanken heute noch deine Logfiles, sind als alleinige Maßnahme auf Dauer zu schwach.

Es ist nicht nur eine Maßnahmen, um Logfiles zu verschlanken. Es reduziert tatsächlich die Anzahl der Verbindungsversuche und damit die Wahscheinlichkeit, daß jemand eindringt. Man kann natürlich auch noch andere Maßnamen ergreifen, als Stichworte sei hier Portknocking und Pingknocking genannt. Damit läßt sich z.B. der SSH-Port völlig nach aussen abschirmen und nur bei Bedarf, für ein kurzes Zeitintervall (z.B. eine Minute) und nur für denjenigen, der die richtige Knocksequenz auslöst, öffnen. Für den Rest der Welt sieht es so aus, als ob kein SSH-Dienst läuft.

[Bryan]

Hallo,

ich habe das mit den Keys mal gemacht, aber wenn ich mich connecten will und "PasswordAuthentication no" einstelle kommt das:

Disconnected: No supported authentication methods available (server sent: publickey)

und mit "PasswordAuthentication yes" kommt das:

Using username "root".
Server refused our key
root@volldiegeheimeadresse's password:

MfG
Bryan

PS: Ich kann englisch und weiß das keine Authentifizierungmöglichkeiten verfügbar sind...
Darauf brauche ich aber eine Lösung wie ich das beheben kann.

[TRex]

ich habe das mit den Keys mal gemacht,

kannst du darauf etwas genauer eingehen? Vielleicht ist dir dabei ja ein Fehler unterlaufen.

[Bryan]

Ich habe das so gemacht wie es in einem Kommentar oben steht...

Irgendwie wird das ja überall so beschrieben?

Wenn ich versuche mich zu verbinden, sagt er:

"Server refused our key"

Woran kann das liegen? Ich finde da nichts drüber?


Ich habe auch mal ein bisschen stackoverflow gelesen und mein LOGLEVEL auf DEBUG3 gestellt. Heraus kam:

Code: Alles auswählen

Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: inetd sockets after dupping: 3, 3
Nov 17 20:30:11 UaChHvnT sshd[12889]: Connection from xx.21.xx.133 port 61577
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.67
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: no match: PuTTY_Release_0.67
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: Enabling compatibility mode for protocol 2.0
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u6
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: fd 3 setting O_NONBLOCK
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: Network child is on pid 12890
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: preauth child monitor started
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: privsep user:group 102:65534 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: permanently_set_uid: 102/65534 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_KEXINIT received [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellm$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cb$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cb$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.co$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.co$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit:  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit:  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: reserved 0  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arc$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arc$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: none,zlib [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: none,zlib [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit:  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit:  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: reserved 0  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: mac_setup: found hmac-sha2-256 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: mac_setup: found hmac-sha2-256 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 0 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive_expect entering: type 1 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: monitor_read: checking request 0
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: inetd sockets after dupping: 3, 3
Nov 17 20:30:11 UaChHvnT sshd[12889]: Connection from xx.21.xx.133 port 61577
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.67
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: no match: PuTTY_Release_0.67
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: Enabling compatibility mode for protocol 2.0
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u6
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: fd 3 setting O_NONBLOCK
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: Network child is on pid 12890
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: preauth child monitor started
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: privsep user:group 102:65534 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: permanently_set_uid: 102/65534 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_KEXINIT received [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellm$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cb$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cb$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.co$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.co$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit:  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit:  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: reserved 0  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arc$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arc$Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: none,zlib [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: none,zlib [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit:  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit:  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_parse_kexinit: reserved 0  [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: mac_setup: found hmac-sha2-256 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: mac_setup: found hmac-sha2-256 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 0 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive_expect entering: type 1 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: monitor_read: checking request 0
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: monitor_read: checking request 0
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_answer_moduli: got parameters: 1024 4096 8192
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 1
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: monitor_read: 0 used once, disabling now
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_choose_dh: remaining 0 [preauth]fie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256$
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: dh_gen_key: priv key bits set: 277/512 [preauth]tr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arc$
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: bits set: 2027/4096 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: bits set: 2018/4096 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_key_sign entering [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 5 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive_expect entering: type 6 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: monitor_read: checking request 5
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_answer_sign
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_answer_sign: signature 0x55c78a843a20(271)
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 6
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: monitor_read: 5 used once, disabling now
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: kex_derive_keys [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: set_newkeys: mode 1 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: cipher_init: set keylen (16 -> 32) [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: set_newkeys: mode 0 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: cipher_init: set keylen (16 -> 32) [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: KEX done [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: userauth-request for user root service ssh-connection method none [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: attempt 0 failures 0 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_getpwnamallow entering [preauth]fie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256$
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 7 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arc$
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive_expect entering: type 8 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: monitor_read: checking request 7
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_answer_pwnamallow
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: Trying to reverse map address xx.21.xx.133.
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: parse_server_config: config reprocess config len 753
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 8
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: monitor_read: 7 used once, disabling now
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: input_userauth_request: setting up authctxt for root [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_start_pam entering [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 50 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_inform_authserv entering [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 3 [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: input_userauth_request: try method none [preauth]
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: monitor_read: checking request 50
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: PAM: initializing for "root"
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: PAM: setting PAM_RHOST to "xxxxxxxx.xxxx.kabel.de"
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug1: PAM: setting PAM_TTY to "ssh"
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: monitor_read: 50 used once, disabling now
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_request_receive entering
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: monitor_read: checking request 3
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug3: mm_answer_authserv: service=ssh-connection, style=, role=
Nov 17 20:30:11 UaChHvnT sshd[12889]: debug2: monitor_read: 3 used once, disabling now
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: userauth-request for user root service ssh-connection method publickey [preauth]1-sha1,rsa2048-sha256$
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: attempt 1 failures 0 [preauth]
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug2: input_userauth_request: try method publickey [preauth]-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arc$
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: test whether pkalg/pkblob are acceptable [preauth]
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_key_allowed entering [preauth]
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 21 [preauth]
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_request_receive_expect entering: type 22 [preauth]
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_request_receive entering [preauth]
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_request_receive entering
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: monitor_read: checking request 21
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_answer_keyallowed entering
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_answer_keyallowed: key_from_blob: 0x55c78a84e730
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: trying public key file /root/&h/.ssh/authorized_keys

Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: Could not open authorized keys '/root/&h/.ssh/authorized_keys': No such file or directory

"Das ist mir gerade ins Auge gefallen, und ich habe es geändert, aber funktioniert immer noch nciht"

Code: Alles auswählen

Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: restore_uid: 0/0
Nov 17 20:30:12 UaChHvnT sshd[12889]: Failed publickey for root from xx.21.xx.133 port 61577 ssh2
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_answer_keyallowed: key 0x55c78a84e730 is not allowed
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 22
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug1: restore_uid: 0/0
Nov 17 20:30:12 UaChHvnT sshd[12889]: Failed publickey for root from xx.21.xx.133 port 61577 ssh2
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_answer_keyallowed: key 0x55c78a84e730 is not allowed
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug3: mm_request_send entering: type 22
Nov 17 20:30:12 UaChHvnT sshd[12889]: debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
Nov 17 20:35:02 UaChHvnT sshd[12871]: debug3: fd 5 is not O_NONBLOCK
Nov 17 20:35:02 UaChHvnT sshd[12871]: debug1: Forked child 12895.
Nov 17 20:35:02 UaChHvnT sshd[12871]: debug3: send_rexec_state: entering fd = 8 config len 753
Nov 17 20:35:02 UaChHvnT sshd[12871]: debug3: ssh_msg_send: type 0
Nov 17 20:35:02 UaChHvnT sshd[12871]: debug3: send_rexec_state: done
Nov 17 20:35:02 UaChHvnT sshd[12895]: debug3: oom_adjust_restore
Nov 17 20:35:02 UaChHvnT sshd[12895]: Set /proc/self/oom_score_adj to 0
Nov 17 20:35:02 UaChHvnT sshd[12895]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 17 20:35:02 UaChHvnT sshd[12895]: debug1: inetd sockets after dupping: 3, 3
Nov 17 20:35:02 UaChHvnT sshd[12895]: Connection from xx.25.xxx.75 port 55482
Nov 17 20:35:02 UaChHvnT sshd[12895]: Did not receive identification string from xxx.25.xx.75

Was soll ich damit anfangen???



MfG
Bryan

[eggy]

Poste die kompletten Configs, sinnlos rumraten macht keinen Spass - zumal "steht da" und "hab ich genauso gemacht, wie der sich das _gedacht_ hat" auch nochmal zwei unterschiedliche Dinge sein können.

[Bryan]

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel DEBUG3

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

[eggy]

Code: Alles auswählen

AuthorizedKeysFile /.ssh/authorized_keys 

Bist Du Dir sicher, dass das so sein soll?

Nachtrag: normalerweise will man, dass die Keys aus dem jeweiligen Home genommen werden, also nicht & sondern %

[Bryan]

Ja woei denn sonst?

AuthorizedKeysFile root/.ssh/authorized_keys

[heisenberg]

Das wäre mal der richtige Fall, wie es sein sollte:

Code: Alles auswählen

AuthorizedKeysFile      %h/.ssh/authorized_keys

%h = Homeverzeichnis des Zielbenutzers.

[eggy]

Siehe den Edit oben, "/root/.ssh" und "root/.ssh" und "%h" können unterschiedliche Verzeichnisse sein.
Das dritte betrifft nicht nur das Home von root (in dem die User nicht rumlesen dürfen sollten) sondern das jeweilige Home des anfragenden Nutzers. Sollte in man sshd_config ausführlich erklärt sein

[Bryan]

Hallo,
ich habe jetzt schon mal Fail2ban installiert, welches auf Hochtouren läuft und erstmal für mehr zeit fü SSH-Keys sorgt...

Kann mir mal vielleicht jemand genau erklären wie das mit denn SSHkeys geht und nicht nur Zeilen #nohate.

Wäre wirklich sehr hilfreich

MfG
Bryan

[trg2889]

Hier wird es gut erklärt
https://www.howtoforge.de/anleitung/key ... mit-putty/
http://www.laub-home.de/wiki/SSH_Key_mi ... _erstellen