Am 02.07.23 um 15:48 schrieb Ulf Volmer:

On 02.07.23 12:36, Peter McD wrote:

...

Mir ist bei einer Leap-Installation gerade aufgefallen, dass bei der Installation, Abschnitt "Authentifizierung für Systemadministrator "root" ein öffentlicher SSH Schlüssel importiert wird. s/wird/werden kann/ Ja, das ist ein ssh pub Key, mit dem Du Dich anschließend als User root authentifizieren kannst. Bei der vorliegenden Installation ist es ein Laufwerksschlüssel.

Ich habe nicht ganz verstanden, was Du mit 'Laufwerksschlüssel' meinst. Nach meinem Sprachgebrauch wäre das ein Schlüssel, mit dem man ein Laufwerk aufsperrt (also z.B. für LUKS).

An der Stelle ist Luks noch weit weg. Es ist die "Authentifizierung für Systemadministrator "root" in der man das root-Passwort festlegt

Das ist die aber nicht der Fall, mit dem Schlüssel sperrst Du einen Benutzer auf. Oder wir reden ganz fürchterlich aneinander vorbei.

An der Stelle gibt es Auswahlmöglichkeiten für die verschiedenen Laufwerke/Partitionen, das ist mir vorher nie aufgefallen. Murphy wird schon dafür gesorgt haben, dass "Schlüssel" eines anderen Laufwerks/Partition dem Bootlaufwerk zugeordnet wurden.

...

Gibt es eine Stelle wo der SSH-Schlüssel nach der Installation an die realen Boot-Verhältnisse angepasst werden kann? /root/.ssh/authorized_keys

ls -la /root/.ssh/authorized_keys ls: Zugriff auf '/root/.ssh/authorized_keys' nicht möglich: Datei oder Verzeichnis nicht gefunden Testweise habe ich eine VM bis zu dem Punkt installiert, da ist zwar das VM-DVD Laufwerk angegeben, aber man sieht, es gibt eine Auswahl. https://1drv.ms/i/s!AtX01xcbBuKCgwb3rRwkQ9wZALbr?e=rMElXv Gruß Peter

Am 02.07.23 um 16:51 schrieb Ulf Volmer:

On 02.07.23 16:47, Peter McD wrote:

...

An der Stelle gibt es Auswahlmöglichkeiten für die verschiedenen Laufwerke/Partitionen, das ist mir vorher nie aufgefallen. Murphy wird schon dafür gesorgt haben, dass "Schlüssel" eines anderen Laufwerks/Partition dem Bootlaufwerk zugeordnet wurden.   [...] https://1drv.ms/i/s!AtX01xcbBuKCgwb3rRwkQ9wZALbr?e=rMElXv

Das wird gefragt, von welcher **Quelle** Du den public Key laden möchtest.

Bedeutet, dass die Laufwerke ein public keys zur Verfügung stellen, die später keinen Einfluss auf die Bootfähigkeiten des installierten Systems hat, sofern das Laufwerk vorhanden ist oder auch nicht??? Wie dem auch sei, mir ist bei der Installation ehe ein Fehler unterlaufen, ich werde genau das Laufwerk auswählen, auf dem ich installiere. Gruß Peter

Am 02.07.23 um 17:37 schrieb Ulf Volmer:

On 02.07.23 17:22, Peter McD wrote:

...

Am 02.07.23 um 16:51 schrieb Ulf Volmer: ... Bedeutet, dass die Laufwerke ein public keys zur Verfügung stellen, die später keinen Einfluss auf die Bootfähigkeiten des installierten Systems hat, sofern das Laufwerk vorhanden ist oder auch nicht???

Das ist die Quelle, aus der der **Installer** den **public Key** des **root users** während der Installation liest.

Warum sollte das einen Einfluß auf die Bootfähigkeit haben?

Das weiß ich nicht und das gefällt mir nicht.>

...

Wie dem auch sei, mir ist bei der Installation ehe ein Fehler unterlaufen, ich werde genau das Laufwerk auswählen, auf dem ich installiere.

Viel Spaß. Wenn Du weder mir noch der Doku Glauben schenkst, wirst Du spätestens dann feststellen, dass in dem genannten Dialog Dein Ziellaufwerk gar nicht auftaucht.

Das hat doch mit Glauben nichts zu tun, ich will verstehen. So die Installation ist wieder angestoßen. Es tauchen alle Laufwerke auf, einschließlich der Bezeichnungen des USB-Sticks mit dem ich installiere. Gewählt habe ich /dev/sda9, die letzte Partition auf der das neue Leap liegen wird. Mal sehen, was das ausgeht. Gruß Peter

Am Sun, Jul 02, 2023 at 06:22:01PM +0200 schrieb Peter McD:

Am 02.07.23 um 17:37 schrieb Ulf Volmer:

...

On 02.07.23 17:22, Peter McD wrote:

...

Am 02.07.23 um 16:51 schrieb Ulf Volmer: ... Bedeutet, dass die Laufwerke ein public keys zur Verfügung stellen, die später keinen Einfluss auf die Bootfähigkeiten des installierten Systems hat, sofern das Laufwerk vorhanden ist oder auch nicht???

Das ist die Quelle, aus der der **Installer** den **public Key** des **root users** während der Installation liest.

Warum sollte das einen Einfluß auf die Bootfähigkeit haben?

Das weiß ich nicht und das gefällt mir nicht.>

Dann mal ganz von vorn: ssh (Secure SHell) ist ein Verfahren, sich über das Netzwerk eine Shell (Also eine CLI Sitzung) von einer entfernten Maschine zu starten. Hier gibt es verschiedene Möglichkeiten zur Authentizierung, verbreitet und sicher ist das Verfahren mit einem private/public Keypair. Hierzu wird mit ssh-keygen ein solches Key Paar erstellt und der öffentliche Teil auf der Zielmaschine in ~/.ssh/authorized_keys abgelegt. Mit dem private Key ist es dann möglich, eine ssh Verbindung zum Ziel herzustellen. Der Suse Installier bietet Dir jetzt die Option, einen solchen public Key für den User root zu hinterlegen. Mit der Bootfähigkeit hat das nicht zu tun. Wenn Du das oben beschriebene Verfahren nicht benötigst, ignoriere die Option im Installer. Wenn Du das später doch noch benötigen solltest, kannst Du pub Keys einfach zur ~/.ssh/authorized_keys hinzufügen. Viele Grüße Ulf

Am Sun, Jul 02, 2023 at 08:06:36PM +0200 schrieb Martin Schröder:

Am So., 2. Juli 2023 um 20:00 Uhr schrieb Ulf Volmer :

...

Der Suse Installier bietet Dir jetzt die Option, einen solchen public Key für den User root zu hinterlegen.

Warum? Best practice ist doch eigentlich, sich *nicht* als root einzuloggen sondern über einen privilegierten User und dann sudo zu benutzen.

Die Frage kann ich nicht beantworten. Das ist jetzt eine Entscheidung von SUSE, über die man in der Tat geteilter Meinung sein kann. Viele Grüße Ulf

Am 02.07.23 um 20:20 schrieb Manfred Kreisl:

Da kann man natürlich geteilter Meinung sein, ob die Ubuntu Philosophie 'Best Practice' ist.

Ich konnte mich damit allerdings nie anfreunden und bin eigentlich immer in ein oder zwei ssh oder Konsole Sessions als root unterwegs. Und das seit über 30 Jahren völlig problemfrei ;)

Manfred

Hier genau dasselbe (: (Einschließlich der 30 Jahre.) Man kann Ubuntu mit ein paar Kommandos dazu bringen, sich auch so zu verhalten. sudo kann in einer wirklichen Mehrbenutzerumgebung aber durchaus sinnvoll sein, wenn man als Admin einzelnen "normalen" Useraccounts root-Rechte zur Verfügung stellen möchte, und im Syslog nachher auch noch sehen will, wer wann als root unterwegs war. -- Viele Grüße Michael Behrens

Am Sun, Jul 02, 2023 at 08:20:57PM +0200 schrieb Manfred Kreisl:

Am 02.07.2023 um 20:06 schrieb Martin Schröder:

...

Am So., 2. Juli 2023 um 20:00 Uhr schrieb Ulf Volmer :

...

Der Suse Installier bietet Dir jetzt die Option, einen solchen public Key für den User root zu hinterlegen.

Warum? Best practice ist doch eigentlich, sich *nicht* als root einzuloggen sondern über einen privilegierten User und dann sudo zu benutzen.

Da kann man natürlich geteilter Meinung sein, ob die Ubuntu Philosophie 'Best Practice' ist.

Ich konnte mich damit allerdings nie anfreunden und bin eigentlich immer in ein oder zwei ssh oder Konsole Sessions als root unterwegs. Und das seit über 30 Jahren völlig problemfrei ;)

In größeren Umgebungen, wo mehrere Personen gemeinsam administrieren, ist es halt schöner auf Loginnamen grep'pen zu können. Man kann zwar auch den verwendeten ssh- Key mitloggen, das ist aber deutlich weniger lesabr. Viele Grüße Ulf

Am Sun, Jul 02, 2023 at 09:07:28PM +0200 schrieb Peter McD:

Danke, damit ist die Unsicherheit bzgl. der Bootfähigkeit ausgeräumt. Bisher habe ich wissentlich keine ssh Verbindung gebraucht, werde aber gerne den SUSE-Schlüssel bunkern.

Es gibt an dieser Stelle keinen SUSE Schlüssel, den Du bunkern könntest. Wenn es eine Keypair gäbe, hättest Du es selber auf einem anderen Rechner generiert und wüsstest davon. Viele Grüße Ulf

Sun, 2 Jul 2023 21:07:28 +0200 Peter McD :

den SUSE-Schlüssel bunkern

Das ist Dein ganz privater Schlüssel für genau diese Installation. Genau genommen ist das kein Schlüssel, sondern einfach nur irgendeine zufällige Identifikation dieses Rechners (Stichwort "host key"). "Das" sind die Dateien /etc/ssh/*key*, welche YaST vor der Formatierung retten kann, oder eben von einer anderen Partition in die neue Installation kopieren kann. Irgendwo in der Dokumentation von SSH steht bestimmt wie wichtig oder unwichtig so ein "host key" ist. Ich bezweifle das YaST während der Installation /root/.ssh anfasst. Olaf

Am 02.07.23 um 16:47 schrieb Peter McD:

ls -la /root/.ssh/authorized_keys ls: Zugriff auf '/root/.ssh/authorized_keys' nicht möglich: Datei oder Verzeichnis nicht gefunden

Offenbar hat der Installer beim Kopieren des Public Keys keinen Erfolg gehabt. Schreib den Public Key deiner Wahl einfach in dieses File und sorge dafür, dass die Permissions so aussehen: (known_hosts* kannst du ignorieren, falls es die nicht gibt.) 20:18:50 root@m1 /root $ l -r .ssh insgesamt 12 -rw-r--r-- 1 root root 1070 12. Nov 2022 known_hosts.old -rw-r--r-- 1 root root 1428 26. Mär 18:35 known_hosts -rw------- 1 root root 392 4. Apr 2021 authorized_keys drwx------ 1 root root 8890 2. Jul 20:18 ../ drwx------ 1 root root 82 15. Nov 2022 ./ -- Viele Grüße Michael Behrens