[GELÖST] SSH Debian testing / Auth per Key mit altem SSH-Server

[cosinus]

Hallo,

mir ist vor ein paar Tagen aufgefallen, dass der openssh-client irgendwie Probleme mit dem Key-Auth hat...zumindest wenn ich mich mit einem SSH-Server verbinden will, der schon ein paar Tage älter ist. Beim Versuch sich zu verbinden, wird immer nach einem Passwort gefragt, obwohl ich den richtigen privaten Schlüssel habe. Mit anderen Server zB Debian stable klappt das wie gewünscht.

Der ältere SSH-Server hat diese SSH-Version:

Code: Alles auswählen

openssh-6.6p1-36.15.0.g3e4df096.rb8
OpenSSH_6.6.1p1, OpenSSL 1.0.2j-fips  26 Sep 2016

Mein Debian Testing hat gerade diese Version:

Code: Alles auswählen

openssh-client 1:8.8p1-1
OpenSSH_8.8p1 Debian-1, OpenSSL 1.1.1m  14 Dec 2021

Mit dem SSH von Debian stable klappt es. Ist der in Debian testing zu neu, weiß da jemand was?


//edit: "GELÖST" im Titel hinzugefügt

[eggy]

Stell mal das Loglevel auf Debug (-v, falls das nicht reicht: mehrere v, -vv, -vvv usw.), dann siehst Du was verwendet wird/werden könnte.

[cosinus]

Ah gute Idee, das mach ich gleich mal

[cosinus]

Code: Alles auswählen

debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /home/arne/.ssh/id_dsa
debug3: no such identity: /home/arne/.ssh/id_dsa: No such file or directory

Wieso versucht der id_dsa und nicht id_rsa als private key? Ich hab nur id_rsa.

[JTH]

Der Grund, warum die Verbindung scheitert, steht ja dort:

Code: Alles auswählen

debug1: send_pubkey_test: no mutual signature algorithm

Ich nehme mal an, dass id_dsa als Rückfallalternative ausprobiert wird. Welche Algorithmen dein Client und Server genau unterstützen (das wird beim Verbindungsaufbau ausgetauscht und ausgehandelt), verrät dir, wie eggy schon geschrieben hat, ein -vv.

Dein SSH-Client ist so konfiguriert – oder sogar so kompiliert – dass er die Verfahren, die dein halbantiker SSH-Server kann – oder durch Konfiguration nur anbietet – nicht unterstützt.

[uname]

Auf dem alten Server müssten doch die alten öffentlichen Schlüssel deines Benutzers z. B. in /home/username/.ssh/authorized_keys rumliegen. Daran sollte man doch erkennen, welche Art von Keys erwartet werden.

[cosinus]

Ja, das ist ein rsa key. Das hat mit dem ja auch sonst immer funktioniert. Aber ist jetzt auch nicht so schlimm, ich kann ja immer noch per Password-Auth rein.
Und mit putty gehts auch mit Key-Auth.

[JTH]

Mit dem SSH von Debian stable klappt es. Ist der in Debian testing zu neu, weiß da jemand was?

Ach, Testing:

Code: Alles auswählen

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

  * New upstream release (https://www.openssh.com/releasenotes.html#8.8p1,
    closes: #996391):
    - This release disables RSA signatures using the SHA-1 hash algorithm by
      default.  (Existing RSA keys may still be used and do not need to be
      replaced; see NEWS.Debian if you have problems connecting to old SSH
      servers.)

und

Code: Alles auswählen

[…]
     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.
[…]

Dein Server hat Version 6.6, deshalb merkst du diese Änderung. Das lässt sich aber durch Konfiguration auf dem Client wieder ändern, siehe den Rest der NEWS-Datei.

[cosinus]

Danke, der Hinweis ist mir leider entgangen