Merci pour ta réponse.
Selon la documentation il est possible d’indiquer un fichier précis. Dans mon cas j’avais ajouté cette ligne car Gitlab ne prenais pas en compte les clefs ajouté sur un profil ou sur un projet pour les déploiements.
C’était un bug de Gitlab => git clone git@... asks for password also if ssh key is added · Issue #103 · YunoHost-Apps/gitlab_ynh · GitHub
AuthorizedKeysFile
Spécifie le fichier contenant les clefs publiques à utiliser pour l’authentification de l’utilisateur. AuthorizedKeysFile peut contenir des jetons de la forme %T qui sont substitués lors des réglages de la connexion. Les jetons suivant sont définis : %% est remplacé par le caractère « % », %h est remplacé par le répertoire de base (home directory) de l’utilisateur qui s’authentifie et %u est remplacé par le nom de cet utilisateur. Après substitution, AuthorizedKeysFile peut être un chemin absolu ou relatif au répertoire de base de l’utilisateur. Par défaut « .ssh/authorized_keys ».
En commentant la ligne il devrait récupérer la valeur par défaut qui devrait s’apparenter à ça:
AuthorizedKeysFile %h/.ssh/authorized_keys
J’ai donc essayé de commenter et d’ajouter manuellement la ligne dans la config mais ca ne fonctionne toujours pas.
Après vérification les changements apportés depuis l’API, sont bien répercutés sur le fichiers authorized_keys de l’utilisateurs.
Pour être sur que le problème ne vienne pas de la façon dont l’API écrit la clef dans le fichier, j’ai tout de même fait un test avec ssh-copy-id et toujours le même problème. Je m’en serait douté mais je voulais être sur. Je pense bien que je ne suis pas la seule personne à utiliser l’API pour gérer les clefs.
Voila un verbose ssh de ce qui se passe lorsque je me connecte:
OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c 28 May 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to *pouetpouet*.fr [*pouetpouet*] port 22.
debug1: Connection established.
debug1: identity file /home/gestion/.ssh/id_rsa type 0
debug1: identity file /home/gestion/.ssh/id_rsa-cert type -1
debug1: identity file /home/gestion/.ssh/id_dsa type -1
debug1: identity file /home/gestion/.ssh/id_dsa-cert type -1
debug1: identity file /home/gestion/.ssh/id_ecdsa type -1
debug1: identity file /home/gestion/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/gestion/.ssh/id_ed25519 type -1
debug1: identity file /home/gestion/.ssh/id_ed25519-cert type -1
debug1: identity file /home/gestion/.ssh/id_xmss type -1
debug1: identity file /home/gestion/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u7
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u7 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to pouetpouet.fr:22 as 'pouet'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
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: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:dPBZDqaM9SsjTM+KmARuL98JgQhnRs+88vLchTXzDrs
debug1: Host pouetpouet.fr' is known and matches the ECDSA host key.
debug1: Found key in /home/gestion/.ssh/known_hosts:3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/gestion/.ssh/id_rsa RSA SHA256:FHJaVzglZesDG9t1PV+15Q9sHyeyAiO+5ROTCgaerL0 agent
debug1: Will attempt key: /home/gestion/.ssh/id_dsa
debug1: Will attempt key: /home/gestion/.ssh/id_ecdsa
debug1: Will attempt key: /home/gestion/.ssh/id_ed25519
debug1: Will attempt key: /home/gestion/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/gestion/.ssh/id_rsa RSA SHA256:FHJaVzglZesDG9t1PV+15Q9sHyeyAiO+5ROTCgaerL0 agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/gestion/.ssh/id_dsa
debug1: Trying private key: /home/gestion/.ssh/id_ecdsa
debug1: Trying private key: /home/gestion/.ssh/id_ed25519
debug1: Trying private key: /home/gestion/.ssh/id_xmss
debug1: Next authentication method: password
J’ai aussi tenté de changer le chmod sur le fichier authorized_keys au cas où. Mais toujours pas.
C’est vraiment étrange sachant que les connexion venant de git fonctionne très bien.
Sur un ordinateur dont la clef publique a été ajouté sur Gitlab si je me connecte avec l’utilisateur git, je suis immédiatement connecté.