Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.os.unix.linux.misc > #118983 > unrolled thread

ssh Schlüssel erneuern oder ersetzen?

Started byBaşar Alabay <alabay@gmx.net>
First post2021-10-20 05:52 +0000
Last post2021-10-24 13:16 +0200
Articles 8 — 5 participants

Back to article view | Back to de.comp.os.unix.linux.misc


Contents

  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

#118983 — ssh Schlüssel erneuern oder ersetzen?

FromBaşar Alabay <alabay@gmx.net>
Date2021-10-20 05:52 +0000
Subjectssh 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]


#118987

FromMarcel Mueller <news.5.maazl@spamgourmet.org>
Date2021-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]


#119009

FromBaşar Alabay <alabay@gmx.net>
Date2021-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]


#119011

FromChristian Garbs <mitch@cgarbs.de>
Date2021-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]


#119017

FromBaşar Alabay <alabay@gmx.net>
Date2021-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]


#119018

FromStefan Reuther <stefan.news@arcor.de>
Date2021-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]


#119023

FromBaşar Alabay <alabay@gmx.net>
Date2021-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]


#119021

FromThomas Hochstein <thh@thh.name>
Date2021-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