Unter Verwendung der Anleitung von Mike (Teil 1) scheitere ich bereits am Anfang bei 4.4.:
Das gesetzte Passwort wird nicht akzeptiert, ein Login auf den Pi gelingt also nicht, obwohl in
der Fritzbox eine feste Adresse gesetzt und das Netzkabel bzw. ggf. Powerkabel gemäß
Anleitung zwecks Speicherung kurz gezogen und neu eingesteckt wurde.
Alternativ habe ich die Anleitung von Bummelstein/Tschaeggaer mit dem selben Image benutzt.
Hier stoppt das Vorgehen bei diesen Zeilen:
„Wir initiieren eine SSH-Sitzung auf dem Pi.
$ ssh 192.168.1.
Ab jetzt geht es auf dem Pi weiter.“
Das tut es bei mir leider nicht!
Auch hier wird das zuvor gemäß hier zitierter Anleitung gesetzte Passwort nicht akzeptiert.
"Wir erstellen uns ein Schlüsselpaar. Dank Passwort-Manager können wir ein
starkes Passwort vergeben.“
Also in beiden Fällen scheitert das weitere Vorgehen an der Akzeptanz der gesetzten Passworte.
Hat jemand dafür eine Erklärung?
Habe ich ggf. etwas übersehen oder falsch verstanden?
Ich glaube mich zu erinnern, dass gelegentlich bei Verwendung der Raspberry Pi Imagers die von mir gewählten Voreinstellungen ignoriert wurden, so dass insbesondere noch das Standard-Passwort aktiv war.
Sind in dem Passwort vielleicht Sonderzeichen drinnen und die englische Tastatur aktiv? Da würde ja schon ein einfacher Unterstrich oder ein Minus stets als falsch ausgewiesen?
Habe ich auch probiert. Also wenn raspberry als Standard gesetzt war auch dies probiert.
Ich habe auch ein sehr einfaches Passwort ohne Snderzeichen probiert, um diese Ursache auszuschließen.
@b4sh: Tja, was soll ich dazu sagen. Bei mir gelingt es nicht.
Ich möchte nochmal betonen, dass ich mich exakt an die Anleitung von Mike bzw. alternativ die von Bummelstein gehalten habe - nur eben jeweils unter Verwendung des Tested Imgage’s von Bookworm 3B.
Nach der Anleitung von Bummelstein hatte es damals problemlos mit Bullseye funktioniert.
Nun wird es Zeit zumindest auf Bookworm zu wechseln, da der Extended Support für Bullseye im Sommer ausläuft.
Die Anleitung von Mike für PiOS Bookworm hat im Gegensatz zu PiOS Trixie funktiioniert.
Aber ich würde das „originale“ Debian doch gegenüber PiOS bevorzugen wollen - entweder nach der Vorlage von Mike oder von Bummelstein.
Außerdem sieht nach dem Login in Pihole unter PiOS Bookworm die Übersicht doch recht anders aus als ich ihn in Bullseye Debian (aktuelleste Updates alle eingespielt!) sehe.
Ich vermute, dass dies auch an PiOS liegen (liegen kann).
Hat noch jemand Ideen warum es wie dargestellt nicht funktionieren könnte?
The image is configured to process the /boot/firmware/sysconf.txt file at boot time
root_pw: Set a password for the root user (by default, it allows for a passwordless login) root_authorized_key: Set an authorized key for a root ssh login. This will allow you to log in remotely.
Verwende auch mal ein ssh root@<deine IP>
Insgesamt möchte ich noch folgendes dazu sagen. Wenn man “irgendwelche“ Images die in den jeweiligen Anleitungen nicht verwendet wurden dennoch benutzen möchte, kann das funktionieren oder eben auch nicht Soweit ich mich erinnere hat nämlich nur Bummelstein deine Variante benutzt. Und ob da das überhaupt mit der “Mike“ Variante mit der userconf funktioniert wage ich zu bezweifeln. Grund s.o.
Welchen Pi verwendest du? Zeigst du uns mal bitte genau, was du in den Dateien /media/SD/sysconf.txt auf der SD-Karte und ~/.ssh/config auf deinem Rechner eingetragen hast?
Schonmal überlegt Container zu verwenden? Damit kann man Inkompatibilitäten umgehen und hat eine getestete Umgebung mit klaren Schnittstellen. So kann man auch problemlos mehrere Services parallel hosten.
Vielen Dank für die weiteren Antworten.
Sorry für meine verzögerte Reaktion. Ich habe in den letzten Stunden weitere Versuche unternommen - leider ohne Erfolg.
Ja, ein Fehler von mir beim Übetragen hier in den Thread. Sorry.
Ja ich weiß Bookworm geht im Juni in den Extended (Community) Support.
Wäre immerhin schon besser als Bullseye, das im Sommer auch damit endet.
Natürlich wäre Trixie sinnvoller, aber ich habe keine an dieses angepasste Anleitung.
Leider habe ich mit Containern bisher keine Erfahrung und suche erstmal nach einer Übergangslösung, um Bullseye beenden zu können.
Also die Anleitung von Bummelstein/Tschaeggaer war im alten Forum von Mike auf das es leider keinen Zugriff mehr gibt. Ich hatte sie mir damals als PDF abgespeichert, was ich hier im Thread wohl kaum wieder geben kann.
Bummelstein hat in seiner Antwort unten im Thread weiter verlinkt:
Muss ich mich noch weiter rein vertiefen.
Jedenfalls habe ich an der sysconf.txt einige Änderungen wie dort in den Kommentaren angegeben vorgenommen und ausprobiert - bisher ohne Erfolg.
Habe ich gemacht - ohne Erfolg.
Ja, dass kann ich gut nachvollziehen. So wundert es mich nicht so sehr, dass es mit dem Debianimage nach der Anlkeitung von Mike nicht klappt.
Aber nach der von Bummelstein sollte es doch funktionieren.
Bummelstein hatte auf Nachfrage in einem Thread hier im Forum dem Threadstarter auch die Anleitung von Mike empfohlen - und sogar gleich den Wechsel auf Trixie angeraten.
Wie oben im Thread erwähnt 3B.
~/.ssh/config
Host 192.168.178.25
IdentitiesOnly yes
IdentityFile ~/.ssh/id_ed25519_pidns
User root
/media/SD/sysconf.txt
Hierin ist nur folgendes verändert, alles andere kommentiert und original belassen!
Ich hoffe, dass ich jetzt auf alle Nachfragen eingegangen bin.
Ich kann nur wiederholen, dass ich nach der Anleitung von Bummelstein spätestens immer wieder daran scheitere, dass nach Setzen „eines starken Rootpassworts“ mittles „passwd“ und folgendem Reboot nach den Updates/Upgrades und Setzen der Locales wie empfohlen mit diesem Passwort nicht mehr in den Pi einloggen kann.
Dabei habe ich bewußt beim Passwort auch auf jegliche Sonderzeichen verzichtet.
Dieses Problem habe ich in Bullseye nie erlebt, wo ich auch Sonderzeichen nutze.
Noch 2 Punkte ergänzend:
Kann es an der Hardware liegen? Es ist auch ein Pi 3B wie oben erwähnt aber nicht der selbe, auf dem noch Bullseye werkelt.
D.h. der Pi mit Bullseye fungiert z.Zt. noch gleichzeitig während der Einrichtung des 2. Pi’s als Pihole-Unbound im Netz.
Und ich habe diverse SD-Karten probiert - auch ohne Erfolg.
Es bleibt mir nur um weitere Hilfe zu bitten.
Es ist generell deutlich hilfreicher für eine Problemlösung, wenn du anstatt mit eigenen Worten zu beschreiben, was passiert ist, exakt schreibst, welchen Befehl du verwendet hast, bei dem ein Fehler aufgetreten ist, und die Fehlermeldung 1:1 hierher kopierst.
Die Dateien sehen erst mal gut aus. Was du probieren könntest, ist alle Überreste der alten Installation zu entfernen und es noch mal zu versuchen. Bei einem weiteren Versuch benötigt es nämlich einen Schritt, der schon öfter vergessen wurde: Du musst die Datei ~/.ssh/known_hosts editieren und dort alle Zeilen entfernen, die mit 192.168.178.25 (deine IP-Adresse für den Pi) beginnen. Dann löschst du noch die vorigen Schlüssel:
Und bei dem neuen Versuch kannst du dann das Passwort für den SSH-Schlüssel mal weglassen (nichts eingeben, nur bestätigen); und zwar bei folgendem Schritt: ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_pidns
Vielen Dank für die aktuellen Antworten und Hinweise!
Wenn alles andere scheitern sollte würde ich das versuchen.
Ich konzentriere mich mal auf die letzten Zeilen des langen Reports, die mir als wohl entscheidend erscheinen.
ssh -vvv username@192.168.178.25
ebug3: kex_input_ext_info: extension publickey-hostbound@openssh.com
debug1: kex_ext_info_check_ver: publickey-hostbound@openssh.com=<0>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/username/.ssh/id_ed25519_pidns ED25519 SHA256:Y69jlv7kCUWi3cpVizMxXETDUTNkUD/aOBo+8hqYLkg explicit
debug2: pubkey_prepare: done
debug1: Offering public key: /home/username/.ssh/id_ed25519_pidns ED25519 SHA256:Y69jlv7kCUWi3cpVizMxXETDUTNkUD/aOBo+8hqYLkg explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Ja, verstehe hatte aber ich hatte hier den Eindruck, dass es so klar werde. Sorry!
Also das mache ich grundsätzlich immer vor einem neuen Versuch, d.h. in ~/.ssh/
lösche ich die beiden Schlüsseldateien wie von dir zitiert sowie „known_hosts“ und „config“.
Das habe ich so gemacht. Aber beim ersten Login auf dem Pi gemäß deiner Anleitung
Wir initiieren eine SSH-Sitzung auf dem Pi.
$ ssh 192.168.1.5
natürlich mit der bei mir veränderten IP also
ssh 192.168.178.25
wird wieder ein Passwort abgefragt.
Diverse Versuche u.a. mit einfach „Enter“ helfen nicht weiter.
Ich hänge schon an dieser Stelle fest und nicht wie sonst wie geschildert nach Updates/Upgrades/Locales und dann „reboot“ mit dem zuvor erstellten Rootpasswort, das dann nicht akzeptiert wird.
Das kommt gleich am Anfang und dann nochmal nach dem Key-Versuch. Bedeutet: Der Server bietet für diesen Benutzer ausschließlich Publickey-Auth an. Passwortauth ist serverseitig nicht verfügbar. Deshalb scheitern alle deine Versuche dich mit einem Passwort anzumelden.
Fazit: Das ganze „Passwort wird nicht akzeptiert“ ist hier schlicht eine Fehlinterpretation. SSH versucht gar kein Passwort. Der Server lässt es nicht zu.
Der Client bietet anschließend den Key id_ed25519_pidns an, aber der Server akzeptiert ihn nicht. Danach bleibt nur noch:
No more authentication methods to try.
Offensichtlich ist der angebotene Public Key auf dem Pi nicht gültig. Das kann mehrere Ursachen haben: Entweder wurde die sysconf.txt nicht korrekt verarbeitet, sodass root_authorized_key (bzw. der Key für den verwendeten Benutzer) nie übernommen wurde, oder der Key in der sysconf.txt stimmt nicht exakt mit dem lokal verwendeten privaten Schlüssel überein. Es kann auch sein, dass mit dem falschen Benutzer eingeloggt wird (z. B. user@…, obwohl der Key nur für root hinterlegt wurde).
Kurz gesagt: Der Server ist auf Publickey-only konfiguriert, aber der passende Key liegt nicht (oder nicht für diesen Benutzer) in authorized_keys vor. Das Passwort spielt hier keine Rolle.
Insgesamt kommt mir das Log auch ziemlich kurz vor, aber auch so scheint die Situation klar zu sein, zumindest was das Passwort betrifft.
Vielen Dank Cyberduck für die ausführliche Erklärung bzw. Deutung!
Hast du eine Idee, was die Ursache sein könnte?
Ich hatte damals bei Bullseye eine andere Linuxdistro - ich denke MXLinux.
Kann das eine Rolle spielen?
Nun ist Bookworm nicht Bullseye.Aber es scheint ja dennoch grundsätzlich möglich mit dieser Anleitung zu sein - so die Posts von Bummelstein und auch anderen Forumsteilnehmern.
Kann es wie schon zuvor gefragt an der Hardware (Pi) liegen?
Gibt es sonst eine Idee, was ich beim Vorgehen versuchen/ändern könnte?
In deinem Setup scheint mir die Datei sysconf.txt der zentrale Punkt zu sein. Wenn du ein raspi.debian.net-Image verwendest, wird der dort eingetragene Public Key beim ersten Boot automatisch in die jeweilige authorized_keys geschrieben. Wenn dieser Vorgang nicht korrekt erfolgt ist, existiert auf dem Pi schlicht kein passender Key – und genau das würde dein Debug-Log erklären.
Typische Fehlerquellen wären zum Beispiel ein Tipp- oder Copy-&-Paste-Fehler im Key, ein falsches Encoding der Datei, eine veränderte Formatierung, ein falscher Dateiname (etwa sysconf.txt.txt) oder ein falscher Benutzerbezug.
Letzteres fällt bei deiner Schilderung besonders auf. Du hast selbst geschrieben, dass in deiner sysconf.txt unter anderem Folgendes steht:
root_authorized_key=ssh-ed25519 AAAA...
Damit hast du einen Public Key für den Benutzer root hinterlegt. In deinem Debug-Log sieht man jedoch einen Login-Versuch mit:
ssh -vvv user@192.168.178.25
Wenn der Key nur für root gesetzt wurde, existiert für user kein entsprechender Eintrag in authorized_keys. Da dein SSH-Server laut Log ausschließlich Public-Key-Login erlaubt, führt das zwangsläufig dazu, dass der Login als user scheitert.
Falls user nur ein anonymisierter Platzhalter für root war, ist alles gut. Wenn nicht, könnte genau hier der eigentliche Fehler liegen.
Da nun die Anleitung (wieder) vorliegt, ( @bummelstein Dankeschön) kann ich dir sagen das dieser Schritt nicht notwendig ist.
Dieser Versuch ist zwar nicht falsch aber im vorliegenden Fall unnötig. Da du ja durch bummelsteins config dafür gesorgt hast das dieser Schritt für dich gemacht wird. Daher sollte auch in deinem Fall ein ssh 192.168.178.25 funktionieren wenn du alles richtig gemacht hast.
Ich befürchte hier werden Dinge vermischt.
Welches Passwort du beim versuch eingeben musst hängt maßgeblich davon ab was du beim erstellen des Key getan hast.
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_pidns
Das andere mit dem passwd ist separat zu betrachten. Du setzt hier “lediglich“ für root überhaupt ein Passwort. Ich erinnere nochmals daran, s.o. default hat root kein Passwort.
Was ich nun machen würde ist folgendes, mache das was du schon ein paar mal teilweise erfolgreich gemacht hast bis zu dem Punkt inklusive passwd und reboot. Danach meldest du dich wieder mit dem gleichen Passwort, falls du bei der Keyerstellung eines gesetzt hast an. Nicht das passwd Passwort. Wenn du kein Passwort bei der Keyerstellung benutzt hast drückst du einfach EINGABE.
Vielen 'Dank Cyberduck und Tulpenknicker für die Antworten!
Also es hat sich bei weiteren Versuchen ein recht „seltsames Spielchen“ ergeben.
Irgendwann konnte ich mit folgendem Command in den Pi einloggen:
ssh -vvv root@192.168.178.25
Akzeptiert wurde das bei der Keyerstellung gesetzte Passwort!
Der Versuch mit „passwd“ ein Rootpasswort gelang, aber:
Dies wurde nach Logouts oder Reboots nicht akzeptiert sondern nur das bei der Keyerstellung
gesetzte Passwort.
Störend waren etwas bei dem o.g. Login die wiederholten vermutlich Debugmeldungen, was sich so darstellte:
Aber ich konnte weiter machen mit Locales, Updates etc.
Mehrfach habe ich mit „reboot“ getestet, ob ich auch noch weiter kommen würde.
Ja, aber mehrfach musste ich auf oben zitierten Command zurückgreifen.
Danach funktionierte es irgendwann auch mit
ssh root@192.168.178.25
bzw.
ssh 192.168.178.25
Manchmal musste ich nach einem Reboot den noch geöffneten Terminal erst schließen und neu öffnen, da erst dann wieder ein Login überhaupt wie o.g. möglich wurde.
Es bleiben Fragen - u.a:
Offensichtlich wird mit „passwd“ das Passwort nicht „root“ zugeordnet.
Enter passphrase for key '/home/unsername/.ssh/id_ed25519_pidns':
folgt
root@192.168.178.25: Permission denied (publickey).
In der Summe, habe ich jetzt den ersten Teil von Bummelstein’s Anleitung absolvieren können,
aber es gibt für mich einige Ungereimtheiten.
Und das Passwort bei der Keyerzeugung hatte ich zunächst bewußt mit Verzicht auf Sonderzeichen und etwas schwächer gewählt. Würde ich gerne stärker wählen - oder ich muss nochmal alles neu aufsetzen.
Habt ihr Erklärungen bzw. weitere Hinweise, die sich für euch aus diesen Ausführungen erkennen lassen?
