Raspberry Pi OS verliert Passwort

L I V E Stammtisch ab 20:30 Uhr im Chat
  • 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.

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • 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.

    Einmal editiert, zuletzt von wend (11. Februar 2021 um 09:33)

  • 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".

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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:

    ssh von anderem PI

    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

    • Offizieller Beitrag

    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. :no_sad:

  • 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:

    Code
    stat /boot/cmdline.txt

    schauen, ob und wann Änderungen an dieser Datei gemacht worden sind.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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 = Read The Factory Manual, oder so

  • 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.

    Einmal editiert, zuletzt von WaldiBVB (12. Februar 2021 um 09:47)

  • 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.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!