Autorisation Git refusée (clé publique) avec la version git la plus récente

Question

Clé créée pour l'autorisation: ssh-keygen -C "your@email.com" -t dsa. Clé publique envoyée à l'administrateur git. Configurez la mise en cache de la phrase secrète en configurant ssh-agent pour Windows. Le processus est décrit à http://help.github.com/ssh-key-passphrases/ Créé .bash_profile. Maintenant, si je travaille dans la console avec le vieux connard 1.9.5 (OpenSSH 6.6.1), il demande qu'une seule fois pour passphrase et je peux cloner/pull/fetch/push, l'authentification est correcte:

$ ssh -vT -p 52967 git@some-repo.com 
OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014 
debug1: Connecting to some-repo.com [XX.XX.XX.XX] port 52967. 
debug1: Connection established. 
debug1: identity file /c/Users/MyName/.ssh/id_rsa type -1 
debug1: identity file /c/Users/MyName/.ssh/id_rsa-cert type -1 
debug1: identity file /c/Users/MyName/.ssh/id_dsa type 2 
debug1: identity file /c/Users/MyName/.ssh/id_dsa-cert type -1 
debug1: identity file /c/Users/MyName/.ssh/id_ecdsa type -1 
debug1: identity file /c/Users/MyName/.ssh/id_ecdsa-cert type -1 
debug1: identity file /c/Users/MyName/.ssh/id_ed25519 type -1 
debug1: identity file /c/Users/MyName/.ssh/id_ed25519-cert type -1 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_6.6.1 
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debia 
n-5ubuntu1.8 
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.8 pat OpenSSH_5* compat 0x0c000000 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client aes128-ctr hmac-md5 none 
debug1: kex: client->server aes128-ctr hmac-md5 none 
debug1: sending SSH2_MSG_KEX_ECDH_INIT 
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY 
debug1: Server host key: RSA aa:a3:0a:32:c2:88:75:a5:5a:c2:05:e6:4b:b1:a0:76 
debug1: Host '[some-repo.com]:52967' is known and matches the RSA host 
key. 
debug1: Found key in /c/Users/MyName/.ssh/known_hosts:1 
debug1: ssh_rsa_verify: signature correct 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: Roaming not allowed by server 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug1: Authentications that can continue: publickey,password 
debug1: Next authentication method: publickey 
debug1: Offering DSA public key: /c/Users/MyName/.ssh/id_dsa 
debug1: Server accepts key: pkalg ssh-dss blen 435 
debug1: Authentication succeeded (publickey). 
Authenticated to some-repo.com ([XX.XX.XX.XX]:52967). 
debug1: channel 0: new [client-session] 
debug1: Requesting no-more-sessions@openssh.com 
debug1: Entering interactive session. 
debug1: Remote: Forced command. 
debug1: Remote: Port forwarding disabled. 
debug1: Remote: X11 forwarding disabled. 
debug1: Remote: Agent forwarding disabled. 
debug1: Remote: Pty allocation disabled. 
debug1: Remote: Forced command. 
debug1: Remote: Port forwarding disabled. 
debug1: Remote: X11 forwarding disabled. 
debug1: Remote: Agent forwarding disabled. 
debug1: Remote: Pty allocation disabled. 
hello MyName, this is git@some-repo-svn running gitolite3 v3.2-10-g2741fad on gi 
t 1.7.9.5 

... Repo list here ... 

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 
debug1: channel 0: free: client-session, nchannels 1 
Transferred: sent 3408, received 3792 bytes, in 1.6 seconds 
Bytes per second: sent 2108.9, received 2346.5 
debug1: Exit status 0 

---

Cependant si j'utilise 2.7.1 Git (de OpenSSH_7.1) moderne J'obtiens l'erreur:

$ ssh -vT -p 52967 git@some-repo.com 
OpenSSH_7.1p2, OpenSSL 1.0.2d 9 Jul 2015 
debug1: Reading configuration data /c/Users/MyName/.ssh/config 
debug1: /c/Users/MyName/.ssh/config line 1: Applying options for some-repo.com 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: Connecting to some-repo.com [XX.XX.XX.XX] port 52967. 
debug1: Connection established. 
debug1: key_load_public: No such file or directory 
debug1: identity file /c/Users/MyName/.ssh/id_rsa type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /c/Users/MyName/.ssh/id_rsa-cert type -1 
debug1: identity file /c/Users/MyName/.ssh/id_dsa type 2 
debug1: key_load_public: No such file or directory 
debug1: identity file /c/Users/MyName/.ssh/id_dsa-cert type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /c/Users/MyName/.ssh/id_ecdsa type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /c/Users/MyName/.ssh/id_ecdsa-cert type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /c/Users/MyName/.ssh/id_ed25519 type -1 
debug1: key_load_public: No such file or directory 
debug1: identity file /c/Users/MyName/.ssh/id_ed25519-cert type -1 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_7.1 
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.8 
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.8 pat OpenSSH_5* compat 0x0c000000 
debug1: Authenticating to some-repo.com:52967 as 'git' 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client aes128-ctr umac-64@openssh.com none 
debug1: kex: client->server aes128-ctr umac-64@openssh.com none 
debug1: sending SSH2_MSG_KEX_ECDH_INIT 
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY 
debug1: Server host key: ssh-rsa SHA256:Zw5XXi0GgafMm6AhcKnNw+GzqkotZwXZYPWrZogG9KQ 
debug1: Host '[some-repo.com]:52967' is known and matches the RSA host key. 
debug1: Found key in /c/Users/MyName/.ssh/known_hosts:1 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug1: Authentications that can continue: publickey,password 
debug1: Next authentication method: publickey 
debug1: Skipping ssh-dss key /c/Users/MyName/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes 
debug1: Trying private key: /c/Users/MyName/.ssh/id_rsa 
debug1: Trying private key: /c/Users/MyName/.ssh/id_ecdsa 
debug1: Trying private key: /c/Users/MyName/.ssh/id_ed25519 
debug1: Next authentication method: password 
git@some-repo.com's password: 
debug1: Authentications that can continue: publickey,password 
Permission denied, please try again. 
git@some-repo.com's password: 
debug1: Authentications that can continue: publickey,password 
Permission denied, please try again. 
git@some-repo.com's password: 
debug1: Authentications that can continue: publickey,password 
debug1: No more authentication methods to try. 
Permission denied (publickey,password). 

config ssh contient des lignes:

Host some-repo.com 
    KexAlgorithms +diffie-hellman-group1-sha1 

Cependant, il ne permet pas. Est-ce que le problème ici est que le serveur utilise l'ancien Git (gitolite3 v3.2-10-g2741fad sur git 1.7.9.5)/SSH (OpenSSH_5.9p1) et qu'il n'y a aucune raison d'utiliser le dernier Git sur le client?

Answer 1

De https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html:

Starting with the 7.0 release of OpenSSH, support for ssh-dss keys has been disabled by default at runtime due to their inherit weakness.
...
If you are stuck with DSA keys, you can re-enable support locally by updating your sshd_config and ~/.ssh/config files with lines like so:

PubkeyAcceptedKeyTypes=+ssh-dss 

Be aware though that eventually OpenSSH will drop support for DSA keys entirely, so this is only a stop gap solution.

Ainsi, la solution est maintenant d'ajouter PubkeyAcceptedKeyTypes=+ssh-dss à votre configuration client ssh.

Answer 2

(je l'ai déjà laissé un commentaire disant ce n'est pas la réponse ... mais peut-être est)

Le 2ème journal dit

debug1: Skipping ssh-dss key /c/Users/MyName/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes 

donc probablement le nouveau serveur a interdit les clés DSA (comme devrait, puisqu'ils sont trop faibles et obsolètes). Utilisez une clé RSA à la place. Et ici, j'ai utilisé 4096 bits ... 2048 devrait probablement être aussi bien, mais ce n'est pas une preuve très futuriste à mon avis; Voir https://www.keylength.com/ pour voir ce que vous en pensez. Le serveur ssh utilise une clé symétrique efficace pour la plupart du travail, donc ce n'est pas vraiment un problème de performance significatif de toute façon ... alors ne vous inquiétez pas à ce sujet. Il faut juste plus de temps pour générer, ce qui est une fois.

ssh-keygen -C “your@email.com” -t rsa -b 4096 

Même si ce serveur pourrait être reconfiguré, ne jamais utiliser les clés DSA ... ils sont de longueur fixe 1024 bits, ce qui est faible par rapport aux normes d'aujourd'hui, obsolète depuis de nombreuses années. 2048 bits est à peine suffisant aujourd'hui (assez pour l'instant, mais pas pour l'avenir). Voir https://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys