Raspberry Pi OS verliert Passwort

  • Zugriff war übers INet, Pi ist auch erreichbar, sonst wäre ja 1, kein Anmeldefehler oder ...

    Welchen ssh-Client mit welchem OS benutzt Du? Wenn Linux (oder gleichwertig) mit ssh, dann poste die richtig anonymisierte Ausgabe von:

    Code
    ssh -v <user>@<IP-Adresse>

    BTW: Wenn man einen genauen ssh-Portscan machen will, benutzt man scanssh. Z. B.:

    Code
    :~# scanssh -s ssh -i eth0 87.230.104.###
    87.230.104.###:22 SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
    Effective host scan rate: 1.43 hosts/s

    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

    • KEIN CLONE ... das Problem tritt bei frisch geflashten System auf, SSH ist per ssh Datei aktiviert worden, lief ja eben auch!
    • Passwort wurde geändert, das schon (und auch das teste ich)
    • LOG liefere ich später nach
    • i.d.R. verwende ich PUTTY, aber von einem andern PI3 aus (auf dem ist das Problem nicht habe) ergibt ssh -v <user>@<IP-Adresse>:
    ssh

    OpenSSH_7.9p1 Raspbian-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 IP-ADRESS port 22.

    debug1: Connection established.

    debug1: SELinux support disabled

    debug1: identity file /home/pi/.ssh/id_rsa type -1

    debug1: identity file /home/pi/.ssh/id_rsa-cert type -1

    debug1: identity file /home/pi/.ssh/id_dsa type -1

    debug1: identity file /home/pi/.ssh/id_dsa-cert type -1

    debug1: identity file /home/pi/.ssh/id_ecdsa type -1

    debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1

    debug1: identity file /home/pi/.ssh/id_ed25519 type -1

    debug1: identity file /home/pi/.ssh/id_ed25519-cert type -1

    debug1: identity file /home/pi/.ssh/id_xmss type -1

    debug1: identity file /home/pi/.ssh/id_xmss-cert type -1

    debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Raspbian-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 IP-ADRESS:22 as 'pi'

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

    The authenticity of host 'IP-ADRESS' can't be established.

    ECDSA key fingerprint is SHA256:xxx.

    Are you sure you want to continue connecting (yes/no)? y

    Please type 'yes' or 'no': yes

    Warning: Permanently added 'IP-ADRESS' (ECDSA) to the list of known hosts.

    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/pi/.ssh/id_rsa

    debug1: Will attempt key: /home/pi/.ssh/id_dsa

    debug1: Will attempt key: /home/pi/.ssh/id_ecdsa

    debug1: Will attempt key: /home/pi/.ssh/id_ed25519

    debug1: Will attempt key: /home/pi/.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/pi/.ssh/id_rsa

    debug1: Trying private key: /home/pi/.ssh/id_dsa

    debug1: Trying private key: /home/pi/.ssh/id_ecdsa

    debug1: Trying private key: /home/pi/.ssh/id_ed25519

    debug1: Trying private key: /home/pi/.ssh/id_xmss

    debug1: Next authentication method: password

    pi@IP-ADRESS's password:

    debug1: Authentications that can continue: publickey,password

    Permission denied, please try again.

    • und scanssh -s ssh -i eth0 87.230.104.###:
    scanssh

    IP_ADRESS:22 SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2

    Effective host scan rate: 2.72 hosts/s

    Einmal editiert, zuletzt von botswanabub (26. Januar 2021 um 13:25)

    • ..., aber von einem andern PI3 aus (auf dem ist das Problem nicht habe) ergibt ssh -v <user>@<IP-Adresse>:
    • und scanssh -s ssh -i eth0 8#.###.###.###:
    Code
    debug1: Authenticating to IP-ADRESS:22 as 'pi'
    ...
    debug1: Next authentication method: password
    pi@xyxyxyxyxyxyx's password:
    debug1: Authentications that can continue: publickey,password
    Permission denied, please try again.

    Wenn das gestern abend aus dem Internet, d. h. mit dieser IP-Adresse, mit diesem user und mit diesem Passwort funktioniert hat und jetzt nicht mehr, kann es m. E. nur am Passwort liegen.

    Hast Du Sonderzeichen im Passwort, hast Du auf deinem Server-PI (mit dem sshd) evtl. eine verschlüsselte Partition? Wird an irgendeiner Stelle evtl. QoS gemacht?

    EDIT:

    Im schlimmsten Fall, hast Du Besuch auf deinem PI gehabt und das Passwort ist geändert worden.

    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

    3 Mal editiert, zuletzt von rpi444 (26. Januar 2021 um 13:44)

  • rpi444 bitte löschen/editieren, ...

    Verstehe nicht, ... was genau soll ich löschen?

    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

  • #43: pi@ HIER STEHT NOCH DER SERVER's password:

    OK, erledigt. D. h. dein PI ist "border device" und damit direkt im Internet.

    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

  • late response ... kam was familiäres dazwischen.

    aktueller Stand: rpi3, neu aufgesetzt, usb stick, standarduser geändert und pi gelöscht.

    lief ein paar Tage, wie lange genau weiß ich nicht. Heute komm ich nicht der drauf per SSH -> access denied!

    gut möglich, dass es wieder Stromausfälle gab. aber das System kann doch nicht so instabil sein? gibt es irgend eine brauchbare LOG, aus der man u.U. was lesen kann?
    ckfs, werde ich noch machen uns nachliefern.

  • kleiner Auszug, mir schwant böses:

    auth.log

    Feb 8 13:18:59 mars sshd[20987]: Failed password for invalid user chris from 106.52.62.56 port 41580 ssh2

    Feb 8 13:19:00 mars sshd[20987]: Received disconnect from 106.52.62.56 port 41580:11: Bye Bye [preauth]

    Feb 8 13:19:00 mars sshd[20987]: Disconnected from invalid user chris 106.52.62.56 port 41580 [preauth]

    Feb 8 13:19:07 mars sshd[20990]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=128.199.143.19 user=root

    Feb 8 13:19:09 mars sshd[20990]: Failed password for root from 128.199.143.19 port 51182 ssh2

    Feb 8 13:19:09 mars sshd[20990]: Received disconnect from 128.199.143.19 port 51182:11: Bye Bye [preauth]

    Feb 8 13:19:09 mars sshd[20990]: Disconnected from authenticating user root 128.199.143.19 port 51182 [preauth]

    Feb 8 13:19:12 mars sshd[20992]: Invalid user zak from 213.32.23.54 port 53012

    Feb 8 13:19:12 mars sshd[20992]: pam_unix(sshd:auth): check pass; user unknown

    Feb 8 13:19:12 mars sshd[20992]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=213.32.23.54

    Feb 8 13:19:14 mars sshd[20992]: Failed

  • Schön, hast Du den Gästen auch schon Bier kaltgestellt und den Grill angeworfen? 8o

    Sieht nach uneingeladenen Besuchern aus.

    Wie ist der Pi denn mit dem Internet verbunden?

    Diese Verbindung würde ich ganz schnell trennen und ggf. auch erst mal das übrige LAN gründlich scannen!

    Gruss

  • Sehr viel interessanter ist das Einfallstor!

    Ich vermute, Du wirst keine feste IP haben, oder?

    Dann evtl. eine Domain, die über DDNS und einen Dienst oder eine Web-Anwendung den Pi erreichbar macht?

    Und da der Thread nun zwei Monate alt ist, ist es natürlich wahrscheinlich, das vom Pi aus weitere Hackversuche unternommen wurden.

    Mit welchem Erfolg, darüber kann man nur spekulieren.

    Für mich wäre das ein Fall um Geld in die Hand zu nehmen und professionelle Hilfe zu suchen, je nachdem, was alles für Daten noch kompromittiert sein könnten.

    Gruss

  • ohne die log genau zu kennen sehe ich auch, dass dies böse ausschaut.
    Gefahr direkt besteht aber keine. Zwar ist das über einen dyndns Account angesteuert, aber er Pi hängt nur mit MagicMirror dran als Display.

    Sonst nichts relevantes.

    Frage ist, liegt das an der DDNS oder einfach zufälliges Opfer? Denn zufällig an zwei unterschiedlichen PI an unterschiedlichen Standorten (den zweiten komme ich erst die Tage dazu aus zulesen).

  • Relevant ist relativ. Wenn da jemand Zugriff hat(te) und Dir den Pi als Teil eines Bot-Netzes einrichtet, dann ist das u.U. nicht lustig.

    Und wie sieht es mit dem Rechner aus, von dem Du auf den Pi zugreifst? Kannst Du ausschliessen, das der infiziert wurde?

    Gruss

    • Offizieller Beitrag

    Sonst nichts relevantes.

    Das stimmt so nicht, denn sonst würde der SSH-Server nicht reagieren, bzw. hättest Du diese Einräge nicht in der auth.log.

    Du hast in Deinem Router eine Portfreigabe erstellt und die muss so schnell wie es geht wieder raus!

    Kannst Du ausschliessen, das der infiziert wurde?

    Das kann man nicht. Ich würde auch hier das gesamte Netzwerk als kompromittiert betrachten.

  • So ganz verstehe ich Eure Hecktik nicht. Das ist doch normales Grundrauschen wenn man einen ssh Server im Internet hat. Login Versuch und 1 Sekunde wieder weg. Das bedeutet nun absolut nicht dass sich jemand auf der Raspi erfolgreich anmelden konnte :no_sad:

    botswanabub Was bekommst Du denn fuer eine Ausgabe von last  und lastlog?

Jetzt mitmachen!

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