Hallo
privat betreibe ich einen mit LUKS verschlüsselten Server unter der Desktop-Version von Ubuntu 20.04.
Das OS und Datenpartitionen sind mit LUKS verschlüsselt. Lokale und entfernte Boot-Freigabe via SSH funktionieren tadellos, z.B. mit Client-PC names "leno".
Letztendlich habe ich eine Anleitung der Zeitschrift c't Heft 17/2021 1:1 umgesetzt.
Dropbear-initramfs-Schlüssel des "leno" ist ein id_ecdsa.pub
.
Der Server bootet von SATA3-SSD und der uP ist ein Vierkerner i5-44xx mit 3,2GHz Takt, 8GB RAM; anno 2013.
Nennen wir den funktionierenden Server "GUT".
Habe zum Kennenlernen von Ubuntu Server 22.04 einen weiteren PC wiederum als verschlüsselten Server mit LUKS aufgesetzt.
Das OS und Datenpartitionen sind ebenfalls mit LUKS verschlüsselt. Das habe ich während der Installation mit dem neuesten Ubuntu-Installer einmalig gewählt; für beide Fälle. Nennen wir diesen Server "zwozwo".
Er bootet von SATA2-HD und ist ein Athlon 64X2 (4450B) mit zwei Kernen, 4GB RAM; anno 2005.
Dropbear-initramfs-Schlüssel ist der id_ecdsa.pub von "leno". "GUT" und "zwozwo" verwenden also den selben öffentlichen Schlüssel für die entferne Boot-Freigabe durch "leno".
Alle Maschinen sind SW-technisch auf neuestem Ubuntu-Stand.
Problem bei "zwozwo":
Lokale Boot-Freigabe funktioniert - aber nicht die entfernte via "leno".
Was ich für "zwozwo" geprüft/gelesen habe:
Infos aus diesem Forum
das Web durchsucht
die Verzeichnisstruktur von dropbear - sie ist bei 22.04 eine andere als noch bei 20.04.
die Rechte der Datei /etc/dropbear/initramfs/authorized_keys: user/group = root mit -rw-xx-xx
dmesg-Ausgaben: Fehlanzeige
/usr/share/doc/dropbear-amfs/README.initramfs
die dropbear-Projektseite in AU und dann alle README's des heruntergeladenen SW-Pakets (scheinen generisch zu sein und nicht zu aktuellen Debian-Systemen zu passen; systemd nein?), daraus abgeleitet: user "dropbear" eingerichtet
/var/log/dropbear: keine Einträge. M.E. richtig so, denn der dropbear-Service sollte ja nicht weiterlaufen nach dem vollständigen Boot
Dort findet sich keine Log's.
/etc/cryptsetup-initramfs/conf.hook: alles auskommentiert. (zum Vergleich "GUT": alles auskommentiert)
/etc/dropbear/initramfs/dropbear.conf hat exklusiv gesetzt:
DROPBEAR_OPTIONS="-c cryptroot-unlock -p 5555"
übrigens identisch mit der von "GUT"
ping: zunächst etwa eine Minute nach Power-On
franzl@leno:~$ ping zwozwo PING zwozwo.fritz.box (192.168.0.zz) 56(84) bytes of data. From leno.fritz.box (192.168.0.ln) icmp_seq=1 Destination Host Unreachable From leno.fritz.box (192.168.0.ln) icmp_seq=2 Destination Host Unreachable From leno.fritz.box (192.168.0.ln) icmp_seq=3 Destination Host Unreachable From leno.fritz.box (192.168.0.ln) icmp_seq=4 Destination Host Unreachable From leno.fritz.box (192.168.0.ln) icmp_seq=5 Destination Host Unreachable From leno.fritz.box (192.168.0.ln) icmp_seq=6 Destination Host Unreachable From leno.fritz.box (192.168.0.ln) icmp_seq=7 Destination Host Unreachable From leno.fritz.box (192.168.0.ln) icmp_seq=8 Destination Host Unreachable From leno.fritz.box (192.168.0.ln) icmp_seq=9 Destination Host Unreachable # da war das System noch nicht weit gekommen im Boot-Vorgang Offenkundig benötigt der "zwozwo" einige Zeit, bis er zur ssh-Verbindungsaufnahme bereit ist. Ist ja auch langsame HW. 64 bytes from zwozwo.fritz.box (192.168.0.zz): icmp_seq=11 ttl=64 time=2634 ms # hier Boot-Vorgang fortgeschritten und ping liefert erwartetes 64 bytes from zwozwo.fritz.box (192.168.0.zz): icmp_seq=12 ttl=64 time=1613 ms 64 bytes from zwozwo.fritz.box (192.168.0.zz): icmp_seq=13 ttl=64 time=589 ms 64 bytes from zwozwo.fritz.box (192.168.0.zz): icmp_seq=14 ttl=64 time=0.271 ms ^C --- zwozwo.fritz.box ping statistics --- 14 packets transmitted, 4 received, +10 errors, 71.4286% packet loss, time 13209ms rtt min/avg/max/mdev = 0.271/1209.242/2634.415/1005.029 ms, pipe 4 Fein. Also nochmal der Versuch der entfernten Boot-Freigabe via SSH "an dropbear-initramfs" franzl@leno:~$ ssh -p 5555 root@192.168.0.zz '''ssh''': connect to host 192.168.0.zz port 5555: Connection refused franzl@leno:~$
Hier zeigt sich nun das Problem:
Connection refused: beim ssh-Verbindungsaufbau mit ssh -p 5555 root@192.168.0.zz kommt diese Meldung bei den Clients "leno" und "GUT"
¶
Fragen:
¶
Wo liegt der Fehler?
Sind PKI-Verfahren zurückgezogen worden?
Gibt es für
dropbear-initramfs
Unterschiede zw. Ubuntu 20.04 Desktop und Ubuntu 22.04 Server bezüglich ...
Funktion
Konfiguration (in 22.04 sind immer wieder mehr Optionen zu finden, die auskommentiert sind)
ssh-FernzugriffLt. der Projektseite https://matt.ucc.asn.au/dropbear/dropbear.html sollen sich OpenSSH und dropbear nicht in die Quere kommen. Das könne man entsprechend setzen. Aber beim Booten; wo, wie?
Vielen Dank für Eure Mühen.
Grüsse
Franzl
Bearbeitet von Berlin_1946:
Forum/Syntax (Abschnitt „Zeilenumbrueche“) korrigiert. War vorher kaum zu lesen 😢
Bearbeitet von Berlin_1946:
Bitte verwende in Zukunft Codeblöcke, um die Übersicht im Forum zu verbessern!