[SSH] ... no matching host key type found

[Andreas Kohlbach]

Ich habe nichts gemacht. [TM]

Gegeben seien zwei Debian Rechner, auf einem läuft testing, auf dem
anderen stable.

Ohne dass ich mir einer Änderung bewusst bin, komme ich mit testing nicht
mehr (ohne Weiteres) per SSH in einen anderen Linux (dort SuSE) rein.

Mit stable geht:

ssh SuSE_Rechner

problemlos. Mit testing bekomme ich dagegen:

| Unable to negotiate with XX.XX.XX.XX port 22: no matching host key
| type found. Their offer: ssh-rsa,ssh-dss
| lost connection

Um da herum zu kommen, gebe ich:

-o 'HostKeyAlgorithms=+ssh-dss'

mit auf den Weg. Aber das kann es doch nicht sein.

Neulich (Feb 18 2022) kam auf testing ein Update rein:

| [UPGRADE] openssh-client:i386 1:8.7p1-4 -> 1:8.8p1-1

Zu der Fehlermeldung finde ich dazu nur den Bug
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841531>, der
allerdings von 2016 und bereits gefixt ist.

Btw. wenn ich direkt über mein Heimnetzwerk von testing nach stable per
SSH gehe, gibt es keine Probleme.
--
Andreas

[Bastian Blank]

Andreas Kohlbach wrote:
> Ich habe nichts gemacht. [TM]

Äh, doch.

> problemlos. Mit testing bekomme ich dagegen:
>| Unable to negotiate with XX.XX.XX.XX port 22: no matching host key
>| type found. Their offer: ssh-rsa,ssh-dss
>| lost connection

Diese Host-Key-Typen sind unsicher. Deshalb akzeptiert sie aktuelles
OpenSSH nicht mehr. Allerdings sind diese seit langem ersetzt durch
rsa-sha2-512 u.ä.

> Btw. wenn ich direkt über mein Heimnetzwerk von testing nach stable per
> SSH gehe, gibt es keine Probleme.

Ach. Was tust du den sonst? Weil ein Debian Bullseye kann ganz klar
rsa-sha2-512 und kein ssh-rsa per default.

Du hast da irgendwo ein SSH-Server, der steinalt ist. Nimm mal "nc" und
zeige was als banner kommt.

Bastian

[Sven Hartge]

Andreas Kohlbach <a...@spamfence.net> wrote:

> | Unable to negotiate with XX.XX.XX.XX port 22: no matching host key
> | type found. Their offer: ssh-rsa,ssh-dss
> | lost connection

openssh (1:8.8p1-1) unstable; urgency=medium

OpenSSH 8.8 includes a number of changes that may affect existing
configurations:

* 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.

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. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination
host:

Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).

-- Colin Watson <cjwa...@debian.org> Tue, 15 Feb 2022 19:20:21 +0000

S°

--
Sigmentation fault. Core dumped.

[Christian Weisgerber]

On 2022-02-27, Andreas Kohlbach <a...@spamfence.net> wrote:

> Ich habe nichts gemacht. [TM]

Weiter unten behauptest du das Gegenteil, nämlich...

> Neulich (Feb 18 2022) kam auf testing ein Update rein:
>| [UPGRADE] openssh-client:i386 1:8.7p1-4 -> 1:8.8p1-1

... dass du eine neue OpenSSH-Version eingespielt hast.

> Ohne dass ich mir einer Änderung bewusst bin, komme ich mit testing nicht
> mehr (ohne Weiteres) per SSH in einen anderen Linux (dort SuSE) rein.
>

>| Unable to negotiate with XX.XX.XX.XX port 22: no matching host key
>| type found. Their offer: ssh-rsa,ssh-dss
>| lost connection

Diese Gegenstelle bietet nur die Signaturalgorithmen ssh-rsa und
ssh-dss an, die beide so veraltet sind, dass sie von aktuellen
OpenSSH-Versionen in der Standardeinstellung nicht mehr unterstützt
werden; ssh-dss schon seit Langem, ssh-rsa seit 8.8.

Entweder läuft auf der Gegenseite ein grotesk veralteter SSH-Server
oder sie ist zerkonfiguriert.

> Um da herum zu kommen, gebe ich:
>
> -o 'HostKeyAlgorithms=+ssh-dss'
>
> mit auf den Weg. Aber das kann es doch nicht sein.

Doch. Also sinnvollerweise ssh-rsa.

Diese Änderung kam nicht unangekündigt. Ab OpenSSH 8.2 steht jedes
Mal in den Release-Notes unter „Future deprecation notice“, dass
ssh-rsa abgeschaltet werden wird, in 8.7 dann „Imminent deprecation
notice“ und in 8.8 dann vollzogen und dokumentiert:

Potentially-incompatible changes
================================

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]

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. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:

Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).

[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Andreas Kohlbach]

On Sun, 27 Feb 2022 07:43:19 -0000 (UTC), Bastian Blank wrote:
>
> Andreas Kohlbach wrote:
>> Ich habe nichts gemacht. [TM]
>
> Äh, doch.

Damit war "keine Änderung" der .ssh/config gemeint (hätte ich sagen
können...).

[...]

>> Btw. wenn ich direkt über mein Heimnetzwerk von testing nach stable per
>> SSH gehe, gibt es keine Probleme.
>
> Ach. Was tust du den sonst?

Normal gebe ich keine weiteren Optionen
(wie "-o 'HostKeyAlgorithms=+ssh-dss'") an.

> Weil ein Debian Bullseye kann ganz klar rsa-sha2-512 und kein ssh-rsa
> per default.
>
> Du hast da irgendwo ein SSH-Server, der steinalt ist.

Der ist

| openssh-server-5.3p1-124.el6_10.x86_64

Laut Suche von April 2019. Graue Vorzeit, ja.

> Nimm mal "nc" und zeige was als banner kommt.

Wie genau? Und auf dem Server oder Client?

Aber OK, dann sollte das am SSH-Server liegen. Er werde mal den Admin
dort stoßen.

Danke auch an die anderen hier.
--
Andreas

[Christian Weisgerber]

On 2022-02-27, Andreas Kohlbach <a...@spamfence.net> wrote:

>> Du hast da irgendwo ein SSH-Server, der steinalt ist.
>

>| openssh-server-5.3p1-124.el6_10.x86_64
>
> Laut Suche von April 2019. Graue Vorzeit, ja.

OpenSSH 5.3 was released on 2009-10-01.
https://www.openssh.com/txt/release-5.3

[Bastian Blank]

Andreas Kohlbach wrote:
>| openssh-server-5.3p1-124.el6_10.x86_64
> Laut Suche von April 2019. Graue Vorzeit, ja.

Nicht ganz, wir dir ja schon erzählt wurde. Allerdings sagt "el6", das
ist RHEL 6, ist out of support seit längerem.

Bastian

[Ralph Angenendt]

Well, Christian Weisgerber <na...@mips.inka.de> wrote:
> On 2022-02-27, Andreas Kohlbach <a...@spamfence.net> wrote:
>
>>> Du hast da irgendwo ein SSH-Server, der steinalt ist.
>>
>>| openssh-server-5.3p1-124.el6_10.x86_64
>>
>> Laut Suche von April 2019. Graue Vorzeit, ja.
>
> OpenSSH 5.3 was released on 2009-10-01.
> https://www.openssh.com/txt/release-5.3

Ja, das da oben ist das Banner eines OpenSSH auf RHEL/CentOS/OEL 6.10.
Das ist die aktuellste Version der Software, RHEL 6 hat sein Leben
allerdings am 30. November 2020 ausgehaucht.

Sprich: Das ist kein reines OpenSSH 5.3, da sind 10 Jahre Patches drin.
Es ist dennoch nicht mehr supported, dieser Rechner hat seit 15 Monaten
(ca.) keine Updates mehr gesehen.

Ralph
--
Übervaterlandverräter und Mutterkornblumenblau

[Marc Haber]

Ralph Angenendt <dein...@strg-alt-entf.org> wrote:
>Sprich: Das ist kein reines OpenSSH 5.3, da sind 10 Jahre Patches drin.

Inklusive modernerer Hashes?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Ralph Angenendt]

Well, Marc Haber <mh+usene...@zugschl.us> wrote:
> Ralph Angenendt <dein...@strg-alt-entf.org> wrote:
>>Sprich: Das ist kein reines OpenSSH 5.3, da sind 10 Jahre Patches drin.
>
> Inklusive modernerer Hashes?

Das kann ich anhand des Changelogs nicht sehen, aber 2016 findet sich
ein Hinweis auf

hmac-sha2-512

im Changelog.