Frage zu öffentlichem SSD/HDD ssh Schlüssel bei der Installation.
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. Bei der vorliegenden Installation ist es ein Laufwerksschlüssel. Eigentlich unkritisch, wenn man nur ein Laufwerk eingebaut hat, allerdings haben sich bei mir vier angesammelt. Ich frage mich, ob es Boot-Probleme geben wird, wenn der Schüssel einer Platte verwendet wird, die aus welchen Gründen auch immer später ausgebaut wird. Gibt es eine Stelle wo der SSH-Schlüssel nach der Installation an die realen Boot-Verhältnisse angepasst werden kann? Gruß Peter
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). Das ist die aber nicht der Fall, mit dem Schlüssel sperrst Du einen Benutzer auf. Oder wir reden ganz fürchterlich aneinander vorbei.
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 Viele Grüße Ulf
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
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. Viele Grüße Ulf
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
On 02.07.23 17:22, Peter McD wrote:
Am 02.07.23 um 16:51 schrieb Ulf Volmer:
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???
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?
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. Viele Grüße Ulf
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:
So die Installation ist wieder angestoßen. Es tauchen alle Laufwerke auf, einschließlich der Bezeichnungen des USB-Sticks mit dem ich installiere.
Wir reden immer noch von dem Dialog "Authentifizierung für Systemadministrator "root"?
Gewählt habe ich /dev/sda9, die letzte Partition auf der das neue Leap liegen wird.
Du mußt schon irgendwas auswählen, wo ein ssh public Key ablegt wurde. Normalerweise ist das ein USB Stick. Viele Grüße Ulf
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 So., 2. Juli 2023 um 20:00 Uhr schrieb Ulf Volmer <u.volmer@u-v.de>:
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. Gruß Martin
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 <u.volmer@u-v.de>:
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.2023 um 20:06 schrieb Martin Schröder:
Am So., 2. Juli 2023 um 20:00 Uhr schrieb Ulf Volmer <u.volmer@u-v.de>:
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 ;) Manfred
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 02.07.23 um 20:34 schrieb Michael Behrens:
... Man kann Ubuntu mit ein paar Kommandos dazu bringen, sich auch so zu verhalten. ...
unterm Strich aus meinem lokalen Archiv. Gruß Peter -------------------------------------- “root”-Nutzer unter Ubuntu aktivieren 5. Oktober 2013 13 Kommentare Tags: FOSS, Nutzer, root, sudo, Ubuntu Unter Ubuntu gibt es in einer Standardinstallation keinen aktivierten „root“-Nutzer. Das bedeutet allerdings nicht das der Nutzer nicht vorhanden ist. Stattdessen wird für den „root“-Nutzer einfach kein Passwort vergeben, was dazu führt das man ihn nicht nutzen kann. Möchte man ihn doch nutzen, so vergibt einfach ein Passwort: sudo passwd root Anschließend verfügt man über einen „root“-Nutzer und kann sich mit diesem einloggen. Möchte man das ganze wieder rückgängig machen, so muss die Datei „/etc/shadow“ bearbeitet werden. Dort wird der Hashwert des Nutzers „root“ einfach durch ein Ausrufezeichen ersetzt. Danach ist der Nutzer wieder deaktiviert und kann nur mittels „sudo“ genutzt werden
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 <u.volmer@u-v.de>:
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 02.07.23 um 20:00 schrieb Ulf Volmer:
Am Sun, Jul 02, 2023 at 06:22:01PM +0200 schrieb Peter McD:
Am 02.07.23 um 17:37 schrieb Ulf Volmer: ...
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.
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. Gruß Peter
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
Am 02.07.23 um 21:34 schrieb Ulf Volmer:
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.
Yast war zufrieden und da das die letzten 20 Jahre ebenso lief, ohne dass mir das aufgefallen wäre, soll mir es recht sein. Sollte ich je ein Schlüsselpaar brauchen, weiß ich jetzt, wen ich fragen kann;-) Danke für die Infos. Gruß Peter
Sun, 2 Jul 2023 21:07:28 +0200 Peter McD <peter.posts@gmx.net>:
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 Sun, Jul 02, 2023 at 09:35:24PM +0200 schrieb Olaf Hering:
Ich bezweifle das YaST während der Installation /root/.ssh anfasst.
Wenn man während der Installation unter "Authentifizierung für Systemadministrator" einen Key bereitstellt, tut er genau das, ja. Davon reden wir ja die ganze Zeit. Viele Grüße Ulf
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
participants (6)
-
Manfred Kreisl -
Martin Schröder -
Michael Behrens -
Olaf Hering -
Peter McD -
Ulf Volmer