ssh-Berechtigung verweigert (publickey) nach dem Upgrade von Fedora 33

Lesezeit: 3 Minuten

ssh Berechtigung verweigert publickey nach dem Upgrade von Fedora 33
Tasche

Ich habe viele Antworten auf diese Stackoverlow-Fragen versucht, genauso wie ich sie jetzt stelle, aber ich kann mein Problem immer noch nicht lösen, ich versuche zu klonen sch aber immer bekommen Permission denied (publickey)

wenn ich laufe GIT_SSH_COMMAND="ssh -vvv" git clone git@bitbucket.org:myusername/my-api.git

debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-rsa SHA256:kkXQOXSRBEiUtuE8AikLLLwbHaxvSc0ojez9YXaGp2A
debug3: hostkeys_foreach: reading file "/home/alienwarepocket/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/alienwarepocket/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from bitbucket.org
debug3: hostkeys_foreach: reading file "/home/alienwarepocket/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/alienwarepocket/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 18.205.93.2
debug1: Host 'bitbucket.org' is known and matches the RSA host key.
debug1: Found key in /home/alienwarepocket/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/alienwarepocket/.ssh/id_rsa RSA SHA256:ktMzaalYyvU9Ev1bgELXatabkUkdcT828O0PppnNiV4M explicit agent
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/alienwarepocket/.ssh/id_rsa RSA SHA256:ktMzaalYyvU9Ev1bgELXatabkUkdcT828O0PppnNiV4M explicit agent
debug1: send_pubkey_test: no mutual signature algorithm
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
git@bitbucket.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Nachdem ich Fedora 33 aktualisiert habe, habe ich dieses Problem, es war kein Problem auf Fedora 32

  • Ich nehme an, dass sich Ihr öffentlicher Schlüssel aufgrund einer Neuinstallation geändert hat. Können Sie versuchen, über https zu klonen?

    – Friedlich

    2. November 2020 um 8:20 Uhr

  • Das ist ein Fehler von Fedora 33, ich habe ihn auf Reddit gefunden, jemand hat den gleichen Fehler @Peaceful gefragt

    – Tasche

    2. November 2020 um 9:31 Uhr


  • Kein Fehler – Fedora 33 ist jetzt entschieden gegen schwache Kryptografie.

    – Jetski S-Typ

    19. November 2020 um 2:55 Uhr

  • Du hattest die richtige Antwort vorher akzeptiert.

    – VonC

    26. November 2020 um 8:20 Uhr

  • Ich habe meine Antwort so bearbeitet, dass sie die enthält update-crypto-policies --set DEFAULT:FEDORA32 Befehl (der Teil des ursprünglich erwähnten Links war)

    – VonC

    26. November 2020 um 10:27 Uhr


1647203889 447 ssh Berechtigung verweigert publickey nach dem Upgrade von Fedora 33
VonC

Das könnte zusammenhängen mit „Änderungen/StrongCryptoSettings2 in Fedora33

Die Änderungen für die Standardrichtlinie sind:

  • Behalten Sie nur TLS 1.2 (und TLS 1.3, falls verfügbar) als aktivierte Protokolle bei und verschieben Sie TLS 1.x, x<=1 auf Legacy-Ebene.
  • Benötigen endliche Feldparameter (RSA, Diffie-Hellman) von 2048 und mehr in den Standardeinstellungen
  • SHA1-Unterstützung für die Verwendung in Signaturen deaktivieren (X.509-Zertifikate, TLS, IPSEC-Handshakes)

Die “Auswirkung von Upgrades/Kompatibilität“Abschnitt des oben genannten Links erwähnt eindeutig:

Es kann sein, dass die neuen Einstellungen Software beschädigen, die sich mit Servern verbindet, die schwache Algorithmen verwenden.
Kompatibilität kann erreicht werden, indem das System auf Fedora 32-Richtlinienebene umgestellt wird:

update-crypto-policies --set DEFAULT:FEDORA32

NICHT EMPFOHLEN obwohl: wenn Sie einen ed25519 verwenden können, ist dies besser.

Wie in Peques Antwort erwähnt, können Sie Ihre hinzufügen ~/.ssh/config eine ursprünglich gefundene Option in sshd_config

 PubkeyAcceptedKeyTypes
         Specifies the key types that will be accepted for public key
         authentication as a list of comma-separated patterns.

Wenn Sie also ed25519 nicht verwenden können, können Sie für einen bestimmten Host die Verwendung von zulassen id_rsa Schlüssel mit:

Host aHost
    Hostname a.hostname.com
    PubkeyAcceptedKeyTypes +ssh-rsa

Zum Schluss: Überprüfen Sie Ihre Berechtigungen nach dem Upgrade noch einmal:

  • ~/.ssh ist 775 drwxrwxr-x.
  • ~/.ssh/id_rsa ist 600 -rw-------.
  • ~/.ssh/id_rsa.pub ist 644 -rw-r--r--.
  • ~/.ssh/config ist 600 -rw-------.
  • ~/.ssh/authorized_keys auf Remote-Server ist 600 -rw-------

Aber mit ssh-keygen -t ed25519 key scheint jetzt empfohlen zu werden.

  • Standard wie beim vorherigen Fedora zu setzen, das wird nicht empfohlen, da das neue in Fedora 33 sicherer ist,

    – Tasche

    26. November 2020 um 10:29 Uhr

  • @Pocket Ja, ich habe gerade die Antwort bearbeitet, um klar zu sagen, dass sie nicht empfohlen wird.

    – VonC

    26. November 2020 um 10:30 Uhr


  • Regenerieren eines Schlüssels mit ssh-keygen -t ed25519 mein Problem mit bitbucket.org behoben.

    – Knarren

    1. Dezember 2020 um 4:44 Uhr


  • Vielen Dank für die Lösung! Bitte fügen Sie der Beschreibung hinzu, dass die Berechtigungen von ~/.ssh/config 600 sein sollten

    – Alexander Arutinjant

    15. Februar 2021 um 9:01 Uhr

  • @AlexanderArutinyants Guter Punkt. Ich habe die Antwort entsprechend bearbeitet.

    – VonC

    15. Februar 2021 um 9:02 Uhr

@VonC Ist richtig, ich habe auf Fedora 33 aktualisiert und bin auf dieses Berechtigungsproblem gestoßen.

das Ausführen des folgenden Befehls hat es behoben:

update-crypto-policies --set DEFAULT:FEDORA32

Vielen Dank für das Teilen dieses Artikels

  • Ich habe auf Fedora 33 aktualisiert und bin auf das gleiche Problem gestoßen. Diese Lösung hat bei mir funktioniert, als ich ein Repository auf Bitbucket verwendet habe

    – Ameise2009

    5. November 2020 um 15:50 Uhr

  • Diese Lösung auf Fedora 33 hat bei mir mit dem Repository auf Gitlab funktioniert

    – Bruno Morais

    16. November 2020 um 18:26 Uhr

  • Um es klar zu sagen, diese Lösung sagt “Ich bin damit einverstanden, schwache Kryptografie zu verwenden”, während die Lösung von VonC das Wurzelproblem behebt und starke Kryptografie verwendet, um Fedora 33 glücklich zu machen.

    – Jetski S-Typ

    19. November 2020 um 2:53 Uhr

  • Es ist viel besser zu verwenden PubkeyAcceptedKeyTypes=+ssh-rsa für die Server, die Sie benötigen, anstatt die Richtlinie global zu ändern. Dies ist von stackoverflow.com/a/65007312/520567

    – Akostadinow

    30. November 2020 um 16:37 Uhr

Anstatt die Kryptorichtlinien global zu ändern, ist es besser, die Sicherheit pro Host herunterzustufen.

Sie können die Konfiguration für den spezifischen Legacy-Host in Ihrem aktualisieren .ssh/config Datei durch Hinzufügen von:

Host legacy.host
    PubkeyAcceptedKeyTypes +ssh-rsa

Weitere Einzelheiten finden Sie hier Diskussion in Bugzilla.

  • Ich bin dem Link gefolgt, danke dafür, und das hatte er PubkeyAcceptedKeyTypes ssh-rsa – so etwas anders, aber es hat bei mir auf Fedora 34 funktioniert.

    – colin0117

    26. Mai 2021 um 17:59 Uhr

998940cookie-checkssh-Berechtigung verweigert (publickey) nach dem Upgrade von Fedora 33

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy