Re: Neue ssh-Konfiugration auf shell

[Marc Haber <mh+uugrn@xxxxxxxxxxxx>]

[gelöschten kontext ergänzt]

On Fri, Sep 25, 2026 at 01:24:24AM +0200, Christian Weisgerber wrote:
> Marc Haber:
> > Christain Weisgerber:
> > > Mir fällt auf, das ecdsa-sha-* abgeschaltet wird, sk-ecdsa-sha2-*
> > > aber nicht.
>
> > Meine Idee wäre gewesen, alles abzuschalten, was sha-1-hashes verwendet.
> > Nach meine Verständnis fallen dort ssh-rsa wie auch ecdsa-sha-* hinein.
>
> Die Verfahren heißen ecdsa-sha2-*. "SHA2". Passend zur 256-, 384-
> und 521(!)-Bit Kurve werden SHA-256, SHA-384 und SHA-512 verwendet.
> (RFC5656)

Ja, deswegen sind die ecdsa-sha2-* Verfahren ja bis auf 
ecdsa-sha2-nistp256 auch erlaubt. Und da es tatsächlich einen User gab, 
der einen ecdsa-sha2-nistp256 Schlüssel verwendet, habe ich dies jetzt 
auch wieder erlaubt.

Ich schrieb oben von abgeschalteten ecdsa-sha-* Verfahren, weil Du Dich 
in dem von Dir selbst nicht mitizitierten und von mir wieder ergänzten 
Abschnitt darüber beklagt hattest, dass ich ecdsa-sha-* abgeschaltet 
hätte.

Ich antwortete Dir fälschlicherweise, ohne vorher geprüft zu haben, ob 
(a) Deine Behauptung überhaupt stimmt und ob es (b) die Verfahren, die 
ich angeblich abgeschaltet habe, überhaupt gibt.

Mein Fehler, und jetzt bin ich verwirrt.

Gibt es an der aktuellen Konfiguration bis auf die Compression noch 
etwas auszusetzen?

> > Im Gegensatz zu dem Stand von gestern ist inziwschen ecdsa-nistp-256 wieder
> > erlaubt; das wird in der Nutzerbasis tatsächlich benutzt.  IMO sollte man
> > das genauso wie RSA2048 oder kleiner so langsam eigentlich rauswerfen.
>
> Naja, die Stärke ist etwa die von Ed25519.

Warum migriert dann die ganze Welt auf Ed25519 wenn das nicht stärker 
ist als RSA2048?

> Der Aufsatz von Bäumer/Brinkmann bastelt jetzt ein etwas kompliziertes
> Angriffsszenario ("a network attacker with access to a forwarded
> TCP port and a web attacker executing JavaScript in the victim’s
> browser via a malicious site"), aber ja, wenn man gegenüber den
> Standardeinstellungen irgendetwas verschärfen will, dann ist
> "Compression no" ein guter Kandidat. Zitat sshd_config(5):
>
>    Compression applies to all traffic that flows over the SSH
>    connection.  If untrusted traffic (such as an open port-forward)
>    is permitted over the connection alongside trusted traffic, then
>    compression may leak information about session contents.  For
>    this reason, it is not recommended to enable compression for
>    connections that share trusted and untrusted traffic.

Das würde ich in erster Näherung dem Benutzer überlassen, Compression 
am Client ggf abzuchalten

Grüße
Marc

--
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

--
Unix User Group Rhein-Neckar e.V.: https://www.uugrn.org
Archiv und An-/Abmeldung:          https://mail2.uugrn.org
Social Media:                      https://social.uugrn.org