Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #118983 > unrolled thread
| Started by | Başar Alabay <alabay@gmx.net> |
|---|---|
| First post | 2021-10-20 05:52 +0000 |
| Last post | 2021-10-24 13:16 +0200 |
| Articles | 8 — 5 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
ssh Schlüssel erneuern oder ersetzen? Başar Alabay <alabay@gmx.net> - 2021-10-20 05:52 +0000
Re: ssh Schlüssel erneuern oder ersetzen? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-10-20 19:01 +0200
Re: ssh Schlüssel erneuern oder ersetzen? Başar Alabay <alabay@gmx.net> - 2021-10-23 12:26 +0000
Re: ssh Schlüssel erneuern oder ersetzen? Christian Garbs <mitch@cgarbs.de> - 2021-10-23 18:31 +0000
Re: ssh Schlüssel erneuern oder ersetzen? Başar Alabay <alabay@gmx.net> - 2021-10-24 07:12 +0000
Re: ssh Schlüssel erneuern oder ersetzen? Stefan Reuther <stefan.news@arcor.de> - 2021-10-24 10:37 +0200
Re: ssh Schlüssel erneuern oder ersetzen? Başar Alabay <alabay@gmx.net> - 2021-10-24 15:32 +0000
Re: ssh Schlüssel erneuern oder ersetzen? Thomas Hochstein <thh@thh.name> - 2021-10-24 13:16 +0200
| From | Başar Alabay <alabay@gmx.net> |
|---|---|
| Date | 2021-10-20 05:52 +0000 |
| Subject | ssh Schlüssel erneuern oder ersetzen? |
| Message-ID | <skoarj$cnb$1@dont-email.me> |
Hallo, bisher nutz(t)e ich RSA Schlüssel, um meine Geräte via CLI miteinander kommunizieren zu lassen (Darwin, Darwin und Raspbian). Es gab schon länger "Gemotze", wenn meine (macports-bestückte!) Darwinkisten den Raspi ansprachen. Nun ist wohl Zopfbeschnitt, ich vermute, aufgrund von openssh 8.8. Auf dem Raspi läuft openssh 7.9. Was tun? Zusätzliche ED… (ich kann mir die Zahl nicht merken) Schlüssel generieren und verteilen? Oder die RSA-Schlüssel alle komplett löschen und mit neuen ED (EDDSA?) ersetzen? Welche Werte wären ratsam? Und sollte man in die Konfigdateien für ssh und/oder sshd anpassen? Oder einfach lassen? Grüße B. Alabay
[toc] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2021-10-20 19:01 +0200 |
| Message-ID | <skpi0l$2nnmm$1@gwaiyur.mb-net.net> |
| In reply to | #118983 |
Am 20.10.21 um 07:52 schrieb Başar Alabay: > bisher nutz(t)e ich RSA Schlüssel, um meine Geräte via CLI miteinander > kommunizieren zu lassen (Darwin, Darwin und Raspbian). Es gab schon > länger "Gemotze", wenn meine (macports-bestückte!) Darwinkisten den > Raspi ansprachen. Was heißt hier Gemotze? RSA ist doch nicht verboten. Sind die Schlüssel vielleicht einfach etwas kurz? > Was tun? Zusätzliche ED… (ich kann mir die Zahl nicht merken) Schlüssel > generieren und verteilen? Oder die RSA-Schlüssel alle komplett löschen > und mit neuen ED (EDDSA?) ersetzen? Neue Schlüssel brauchst du so oder so, wenn du RSA nicht mehr nutzen möchtest. Und die müssen ohnehin alle im Server registriert werden. Danach sind die alten Schlüssel für dich bedeutungslos. Und natürlich sollte man sie, wenn man sie nicht mehr braucht auch nicht mehr akzeptieren. Insofern verstehe ich die Frage nicht. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Başar Alabay <alabay@gmx.net> |
|---|---|
| Date | 2021-10-23 12:26 +0000 |
| Message-ID | <sl0v2e$gem$1@dont-email.me> |
| In reply to | #118987 |
Marcel Mueller schrieb: > Am 20.10.21 um 07:52 schrieb Başar Alabay: >> bisher nutz(t)e ich RSA Schlüssel, um meine Geräte via CLI miteinander >> kommunizieren zu lassen (Darwin, Darwin und Raspbian). Es gab schon >> länger "Gemotze", wenn meine (macports-bestückte!) Darwinkisten den >> Raspi ansprachen. > > Was heißt hier Gemotze? RSA ist doch nicht verboten. NIcht direkt verboten, aber ihre Nutzung wurde wohl beim letzten Update von openssh default erstmal kassiert. > Sind die Schlüssel vielleicht einfach etwas kurz? Das denke ich nicht, die waren recht groß. >> Was tun? Zusätzliche ED… (ich kann mir die Zahl nicht merken) Schlüssel >> generieren und verteilen? Oder die RSA-Schlüssel alle komplett löschen >> und mit neuen ED (EDDSA?) ersetzen? > > Neue Schlüssel brauchst du so oder so, wenn du RSA nicht mehr nutzen > möchtest. Und die müssen ohnehin alle im Server registriert werden. > Danach sind die alten Schlüssel für dich bedeutungslos. Und natürlich > sollte man sie, wenn man sie nicht mehr braucht auch nicht mehr > akzeptieren. Insofern verstehe ich die Frage nicht. Ich wollte wissen, ob man nur einen Typ Schlüssel generieren/haben soll oder mehrere (die dann parallel benutzt werden). Nun habe ich die RSA-Schlüssel überall gelöscht und sauber mit ED25519 ersetzt. Das Mac-Umfeld hatte dann aber durchaus noch ein paar interessante Fallstricke, da dort die Implementation des Keychains nur mit dem onboard-ssh läuft (und nicht via openssh). Das umschifft … der ssh-agent scheint unter Linux und Darwin gleichermaßen angestoßen zu werden. Jetzt läuft alles. B. Alabay
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2021-10-23 18:31 +0000 |
| Message-ID | <sl1kek$lusp$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #119009 |
Mahlzeit!
Başar Alabay <alabay@gmx.net> wrote:
> Ich wollte wissen, ob man nur einen Typ Schlüssel generieren/haben
> soll oder mehrere (die dann parallel benutzt werden).
Es lohnt vermutlich nicht, zu einem Zielsystem mehrere verschiedene
Schlüsseltypen zu haben.
Was sich lohnen kann, sind unterschiedliche Schlüssel für
unterschiedliche Zielsysteme. Wenn da mal ein privater Key wegkommt,
musste Du im Idealfall nur einen Schlüssel auf einem System tauschen
und nicht gleich alle. Außerdem kannst Du jedem der Schlüssel ein
anderes Passwort verpassen.
Außerdem kannst Du so bei z.B. einem Altsystem (Dein Mac-Umfeld ohne
Problem-Umschiffung ;-) auf RSA bleiben und auf allen anderen ED25519
nutzen.
Das könnte z.B. so aussehen in .ssh/config
Host system1
Hostname system1.langer.domainname.example.bla
IdentityFile ~/.ssh/id_ed25519-system1
Host legacy
IdentityFile ~/.ssh/id_rsa-legacy
Host github.com
IdentityFile ~/.ssh/id_ed25519-github
Und auch bei gleichem Zielsystem können mehrere Schlüssel sinnvoll
sein: Z.B. ein Schlüssel mit Passwort für den normalen SSH-Zugang und
zusätzlich ein weiterer Schlüssel ohne Passwort für automatisierte
Backups per crontab. Da sollte man dann allerdings auf dem Zielsystem
einstellen, dass der passwortlose Schlüssel nur ganz bestimmte
Kommandos ausführen darf.
Beispiel aus /home/borg/.ssh/authorized_keys:
command="borg serve --append-only --restrict-to-path /home/borg/system1",restrict ssh-ed25519 AAAA...Cx4 user@system1
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Keine Homepage? Keine Ahnung? Keine Idee?
Dann mirror Dir einen!
[toc] | [prev] | [next] | [standalone]
| From | Başar Alabay <alabay@gmx.net> |
|---|---|
| Date | 2021-10-24 07:12 +0000 |
| Message-ID | <sl310u$ss0$2@dont-email.me> |
| In reply to | #119011 |
Christian Garbs schrieb: >> Ich wollte wissen, ob man nur einen Typ Schlüssel generieren/haben >> soll oder mehrere (die dann parallel benutzt werden). > > Es lohnt vermutlich nicht, zu einem Zielsystem mehrere verschiedene > Schlüsseltypen zu haben. > > Was sich lohnen kann, sind unterschiedliche Schlüssel für > unterschiedliche Zielsysteme. Wenn da mal ein privater Key wegkommt, > musste Du im Idealfall nur einen Schlüssel auf einem System tauschen > und nicht gleich alle. Außerdem kannst Du jedem der Schlüssel ein > anderes Passwort verpassen. Jetzt habe ich alles auf ED gesetzt. Drei Schlüssel mit jeweils unterschiedlichen Paßworten. > Außerdem kannst Du so bei z.B. einem Altsystem (Dein Mac-Umfeld ohne > Problem-Umschiffung ;-) auf RSA bleiben und auf allen anderen ED25519 > nutzen. Es sind doch meine Altsysteme, die das neue openssh haben :-) Macports sei Dank. > Das könnte z.B. so aussehen in .ssh/config > > Host system1 > Hostname system1.langer.domainname.example.bla > IdentityFile ~/.ssh/id_ed25519-system1 > > Host legacy > IdentityFile ~/.ssh/id_rsa-legacy > > Host github.com > IdentityFile ~/.ssh/id_ed25519-github In der config habe ich bis jetzt noch nicht so viel gebastelt. > Und auch bei gleichem Zielsystem können mehrere Schlüssel sinnvoll > sein: Z.B. ein Schlüssel mit Passwort für den normalen SSH-Zugang und > zusätzlich ein weiterer Schlüssel ohne Passwort für automatisierte > Backups per crontab. Da sollte man dann allerdings auf dem Zielsystem > einstellen, dass der passwortlose Schlüssel nur ganz bestimmte > Kommandos ausführen darf. > > Beispiel aus /home/borg/.ssh/authorized_keys: > command="borg serve --append-only --restrict-to-path > /home/borg/system1",restrict ssh-ed25519 AAAA...Cx4 user@system1 Ich hatte früher paßwortlose Schlüssel für die ssh-Connects, dieses Einengen hatte ich nicht auf dem Schirm. Und ich glaube, da müßte ich mich dann tiefer einlesen. Danke für Deine Infos. B. Alabay
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2021-10-24 10:37 +0200 |
| Message-ID | <sl3d15.5e8.1@stefan.msgid.phost.de> |
| In reply to | #119009 |
Am 23.10.2021 um 14:26 schrieb Başar Alabay: > Marcel Mueller schrieb: >> Am 20.10.21 um 07:52 schrieb Başar Alabay: >>> bisher nutz(t)e ich RSA Schlüssel, um meine Geräte via CLI miteinander >>> kommunizieren zu lassen (Darwin, Darwin und Raspbian). Es gab schon >>> länger "Gemotze", wenn meine (macports-bestückte!) Darwinkisten den >>> Raspi ansprachen. >> >> Was heißt hier Gemotze? RSA ist doch nicht verboten. > > NIcht direkt verboten, aber ihre Nutzung wurde wohl beim letzten Update > von openssh default erstmal kassiert. Du hast keine Fehlermeldung gepostet, und ich habe auch aktuell kein passendes System(-Paar) parat zum selbst testen, aber als ich das letzte Mal eine Meldung bekam, die in die Richtung ging, ergab Eingabe der Fehlermeldung im Wortlaut in eine Suchmaschine des Vertrauens eine Einstellung für die clientseitige Konfiguration, um den Schlüssel dennoch zu verwenden. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Başar Alabay <alabay@gmx.net> |
|---|---|
| Date | 2021-10-24 15:32 +0000 |
| Message-ID | <sl3ua8$efl$4@dont-email.me> |
| In reply to | #119018 |
Stefan Reuther schrieb: >>>> bisher nutz(t)e ich RSA Schlüssel, um meine Geräte via CLI miteinander >>>> kommunizieren zu lassen (Darwin, Darwin und Raspbian). Es gab schon >>>> länger "Gemotze", wenn meine (macports-bestückte!) Darwinkisten den >>>> Raspi ansprachen. >>> >>> Was heißt hier Gemotze? RSA ist doch nicht verboten. >> >> NIcht direkt verboten, aber ihre Nutzung wurde wohl beim letzten Update >> von openssh default erstmal kassiert. > > Du hast keine Fehlermeldung gepostet, und ich habe auch aktuell kein > passendes System(-Paar) parat zum selbst testen, aber als ich das letzte > Mal eine Meldung bekam, die in die Richtung ging, ergab Eingabe der > Fehlermeldung im Wortlaut in eine Suchmaschine des Vertrauens eine > Einstellung für die clientseitige Konfiguration, um den Schlüssel > dennoch zu verwenden. Ja. Dem war so. Ich wollte aber kein obsoletes Etwas per Aufbohrung halbtot weitertragen. Bis ich bei allen Rechnern umgestellt hätte … da mache ich doch lieber gleich neue Schlüssel. B. Alabay
[toc] | [prev] | [next] | [standalone]
| From | Thomas Hochstein <thh@thh.name> |
|---|---|
| Date | 2021-10-24 13:16 +0200 |
| Message-ID | <dcoulm.20211024131641.2445@scatha.ancalagon.de> |
| In reply to | #118987 |
Marcel Mueller schrieb: > Was heißt hier Gemotze? RSA ist doch nicht verboten. <https://www.openssh.com/txt/release-8.8> | This release disables RSA signatures using the SHA-1 hash algorithm | by default. This change has been made as the SHA-1 hash algorithm is | cryptographically broken, and it is possible to create chosen-prefix | hash collisions for <USD$50K [1] Das betrifft allerdings nur RSA mit SHA-1. | For most users, this change should be invisible and there is | no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 | RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys | will automatically use the stronger algorithm where possible. | | Incompatibility is more likely when connecting to older SSH | implementations that have not been upgraded or have not closely tracked | improvements in the SSH protocol. -thh
[toc] | [prev] | [standalone]
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web