Wow, starke Behauptung
Stimmt, denn es wird in o.g. Fall ein deutlicher Warnhinweis ausgegeben und explizit nicht einfach "press enter" eingefordert.
Wen das nicht hellhörig macht, unabhängig vom Kenntnisstand... s.o.
Wow, starke Behauptung
Stimmt, denn es wird in o.g. Fall ein deutlicher Warnhinweis ausgegeben und explizit nicht einfach "press enter" eingefordert.
Wen das nicht hellhörig macht, unabhängig vom Kenntnisstand... s.o.
Raspberry Pi OS verliert Passwort? Schau mal ob du hier fündig wirst!
also mit einem anderen Rechner bin ich/war ich definitiv nicht verbunden, mag sein, dass dies eine Fehlerquelle per se ist, aber in dem Fall nicht zutreffend.
Woran merkst Du das? Dass es wirklich der richtige Rechner ist. Ein Gefühl, dass das so ist, ist zwar OK, aber bei einem so seltsamen Problem muss man schon etwas genauer hingucken. Z.B. hast Du weiter oben mal gesagt, dass du dich von einem anderen Pi per ssh einloggst, und weiter unten, auf die Nachfrage, welche anderen Rechner Du betreibst, gesagt, dass kein weiterer Rechner angeschlossen sei. Du musst wirklich genau arbeiten. Jede kleine Info kann ein Hinweis auf die Ursache des Problems sein, und da musst Du uns schon die Chance geben, indem Du arkribisch genau die Fakten beschreibst.
Woran merkst Du das? Dass es wirklich der richtige Rechner ist.
Sonst kommt ein FETTER Warnhinweis, dass der Hostkey nicht mit dem gespeichertem übereinstimmt.
Passiert z.B. wenn ein Host eine IP verwendet, auf der sich schon ein anderer Host gemeldet hat.
Der Client merkt sich dieses Key und wenn der sich ändert, kommt der Warnhinweis und die Verbindung wird abgelehnt.
So habe ich z.B. herausgefunden, dass sich ein anderer Kunde im RZ meine IP zugewiesen hat.
In schlecht gemanagten Netzwerken ist sowas möglich.
Zum Glück geht es bei den meisten Rechenzentren nicht, da die ihr Netzwerk im Griff haben.
ja es ist kein anderer PC/PI in diesem Netzwerk angeschlossen, ich habe bei den beiden Problem PI folgende Konfiguration:
1. ROUTER (Standort 1):
-> PI
-> SAT
-> TV
-> hin und wieder ein Handy
2. ROUTER (Standort 2):
-> PI
-> ARLO Basis
daher ist das Einloggen auf einem falschen PI nicht möglich. Zumal, zugegebener weise fahrlässig, ich im ersten Augenblick bei beiden die gleichen Zugangsdaten hatte. Selbst wenn ich am falschen PI gewesen sein möchte, dann müsste der Login klappen.
ja es ist kein anderer PC/PI in diesem Netzwerk angeschlossen, ....
daher ist das Einloggen auf einem falschen PI nicht möglich. Zumal, zugegebener weise fahrlässig, ...
Wenn Du es genau wissen willst, ob es einen Zusammenhang zwischen "PI verliert Passwort" und Anmeldung via ssh mit Passwort gibt, erstellst Du keys (für die Anmeldung mit pub-key), benutzt nur dieses Verfahren und deaktivierst (temporär) die Anmeldung per Passwort. BTW: Wenn es dann noch weitere Fragen/Ungereimtheiten gibt, kann man die Anmeldung per pub-key zusätzlich optimieren/"verfeinern".
Wie meldet dich der Pi denn, bevor(!) Du ein login-passwort eingibst? Kannst Du mal eine text Ausgabe hier reinposten?.
Oder besser noch mit "ssh -v", dann aber meinetwegen die geheimen Schluessel aus dem log entfernen....
Sonst kommen wir hier doch nicht weiter....
normal melde ich mich über putty an, dann steht da login as:
nun mal aus Linux heraus mit ssh USER@HOST -p xxxx -v:
MYUSER@CURRENTHOST:~ $ ssh MYUSER@MYHOST -p MYPORT -v
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to MYHOST [MYIP] port MYPORT.
debug1: Connection established.
debug1: identity file /home/MYUSER/.ssh/id_rsa type -1
debug1: identity file /home/MYUSER/.ssh/id_rsa-cert type -1
debug1: identity file /home/MYUSER/.ssh/id_dsa type -1
debug1: identity file /home/MYUSER/.ssh/id_dsa-cert type -1
debug1: identity file /home/MYUSER/.ssh/id_ecdsa type -1
debug1: identity file /home/MYUSER/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/MYUSER/.ssh/id_ed25519 type -1
debug1: identity file /home/MYUSER/.ssh/id_ed25519-cert type -1
debug1: identity file /home/MYUSER/.ssh/id_xmss type -1
debug1: identity file /home/MYUSER/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Raspbian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Raspbian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to MYHOST:MYPORT as 'MYUSER'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:G9Fed/6rlkR2C8vKf9ZrSfbFlMPMM6i1PeW9wN4yxjo
debug1: Host '[MYHOST]:MYPORT' is known and matches the ECDSA host key.
debug1: Found key in /home/MYUSER/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/MYUSER/.ssh/id_rsa
debug1: Will attempt key: /home/MYUSER/.ssh/id_dsa
debug1: Will attempt key: /home/MYUSER/.ssh/id_ecdsa
debug1: Will attempt key: /home/MYUSER/.ssh/id_ed25519
debug1: Will attempt key: /home/MYUSER/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/MYUSER/.ssh/id_rsa
debug1: Trying private key: /home/MYUSER/.ssh/id_dsa
debug1: Trying private key: /home/MYUSER/.ssh/id_ecdsa
debug1: Trying private key: /home/MYUSER/.ssh/id_ed25519
debug1: Trying private key: /home/MYUSER/.ssh/id_xmss
debug1: Next authentication method: password
MYUSER@MYHOST's password:
debug1: Authentication succeeded (password).
Authenticated to MYHOST ([MYIP]:MYPORT).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
Linux XXXX 5.10.11-v7+ #1399 SMP Thu Jan 28 12:06:05 GMT 2021 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Feb 11 19:20:39 2021 from xxx.xxx.xxx.xxx
ssh MYUSER@MYHOST -p MYPORT -v
Der Port ist auch nicht default 22 oder?
zugegeben, zunächst war er das (also 22). nun habe ich das geändert. zumal ist es letztlich nicht egal, wenn die IP nach offenen ports scannen kommen se irgendwann auf jeden?
zumal ist es letztlich nicht egal, wenn die IP nach offenen ports scannen kommen se irgendwann auf jeden?
Ja, aber eben erst *irgendwann*. Für mich ist nach wie vor das Problem klar. Ein Passwort ändert oder löscht sich halt nicht von allein.
bin ich voll bei dir hyle, ergo bleibt ja nur noch ein einbruch ...
dann aber wäre ich erstaunt, dass sie ein 10 Stelliges PW meines Users geknackt haben ... in so kurzer Zeit.
Nun mal sehen wie lange es nun läuft: neuer user, neuer port, neue URL und andere PWs. Zumindest von gestern bis heute keine Anmeldeversuche und ein noch funktionierendes PW
..., ergo bleibt ja nur noch ein einbruch ...
dann aber wäre ich erstaunt, dass sie ein 10 Stelliges PW meines Users geknackt haben ... in so kurzer Zeit.
BTW: Bei jedem erfolgreichen Einbruch via Internet entsteht eine Änderung der Datei "/run/utmp". Es gibt Software die die Änderung dieser Datei sofort erkennt und sofort (d. h. noch bevor der Einbrecher in der Lage ist das zu ändern) eine eMail an dich senden kann. Evtl. mal testen.
Es könnte aber auch ein "Einbruch vor Ort" sein. D. h mit Zugang zur bzw. mit Hilfe der SD-Karte und dafür muss das Passwort nicht bekannt sein. Der Einbrecher kann z. B. mit dem temporärem Eintrag "init=/bin/sh" in der cmdline.txt, auch das Passwort ändern. Wo steht den PI und wer hat in deiner Abwesenheit, evtl. Zugang zu diesem PI? Evtl. auch mit:
schauen, ob und wann Änderungen an dieser Datei gemacht worden sind.
dann aber wäre ich erstaunt, dass sie ein 10 Stelliges PW meines Users geknackt haben
Ich habe es schon mal erwähnt: man braucht kein PW zu knacken! Es reicht, wenn die Software irgendwo einen Exploit hat, den der Angreifer nutzen kann, um sich Zugang zum System zu verschaffen.
Gruss
was mir noch aufgefallen ist, was ist das?
CRON[3911]: pam_unix(cron:session): session opened for user root by (uid=0)
FSC830 die Software ist RPI OS mit MagicMirror darauf, mehr nicht. Mir ist nix in MM bekannt, zumindest was ich recherchieren konnte und gut wenns ein problem mit ROS gibt ... dann blöd
ach ja, und alles immer up2date gehalten.
dann aber wäre ich erstaunt, dass sie ein 10 Stelliges PW meines Users geknackt haben ... in so kurzer Zeit.
Glaubst wirklich, dass ein Einbrecher mit Loginversuchen am Pi Dein Passwort zu erraten versucht ?
Die Zugangsdaten holt er sich vom Windows PC und/oder meldet sich zum Passwortwechsel gleich vom PC per SSH am Pi ein.
Und est wäre naiv anzunehmen, dass nur das Passwort gewechselt wurde. Der Pi hat schon längst ein Schadprogramm drauf.
Servus !
RTFM sorry, aber das macht doch keinen Sinn. Ersten ist mein Windows PC definitiv sauber (kannst mir glauben, dass ist meine Domäne). Zweits ist da nirgends das Passwort hinterlegt welches am RPI genutzt wird. Das schließe ich aus.
Das mit irgend nem Schadprogramm wäre denkbar, aber dann werde ich das ja sehen. Kaputt machen kann mir da keiner was. Daten klauen auch nicht ...
In dem Sinne, kann jemand hier ein Tool empfehlen das die Log Dateien aufbereiten kann und eine Statistik für den Webbrowser erstellt? Also nicht nur die Nginx Logs sondern auch Auth und was da halt noch so verfügbar ist.
PS: meine Vermutung ist das das Problem wo anders liegt und nicht durch einen "Einbrecher" verursacht wird. Ist aber nur so ein Gefühl.
kurzes aktuelles Feedback: user gewechselt, pw sowieso, port gewechselt und seit ein her ist bis dato ruhe ... mal sehen wann se den finden.
Interessant ist das Einfallsreichtum mit dem Versucht wird da einzudringen. Nun eine Frage, könnte es sein, dass durch die permanenten Logins das System einfach sperrt und ich daher nicht mehr rein komme?
Anbei lastb Auszug
Nun eine Frage, könnte es sein, dass durch die permanenten Logins das System einfach sperrt und ich daher nicht mehr rein komme?
Wenn dein System nicht richtig konfiguriert ist, kann das passieren.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!