Problème SSH / GitLab

Mon serveur YunoHost

Matériel: PC x86-64bits (Ryzen3, 16Go RAM, 2x2To + 512Go SSD)
Version de YunoHost: 3.7.0.12
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : oui
Si oui, expliquer:
Yunohost installer sur une Debian toute fraîche (il y a un an)

Description du problème

Jusqu’à aujourd’hui, j’utilisais yunohost pour quelques services (Nextcloud, TTRSS, Wallabag) sur un sous domaine “maison.arofarn.info”, sans soucis particulier, y compris accès SSH. :slight_smile:

J’ai installé Gitlab en plus et pour ce faire, j’ai ajouté un sous-domaines “git.arofarn.info”. Toute la partie web fonctionne bien. :slight_smile:

Par contre, la connexion SSH est refusée vers ce nouveau domaine. J’ai créé une paire de clefs ed25519 pour GitLab, pus j’ai ajouté la clef publique à mon compte gitlab comme indiquer dans la doc. J’ai aussi ajouté cette nouvelle paire à ssh-agent et ajouté une entrée dans mon ~/.ssh/config .
Mais je finis systématiquement sur une erreur : Permission denied (publickey)

J’ai la même erreur avec:

  • l’utilisateur “git” avec l’outils git comme avec la commande ssh (y compris en précisant le fichier d’identité avec “ssh -i ma_clef_specifique_gitlab”)
  • le compte “admin” (qui continue de se logger avec succès avec le premier domaine ou l’adresse IP locale)

Du coup, je pense que c’est plutôt un problème de configuration côté serveur SSH/domaine que côté client ou gitlab. :confused:
Un sudo service ssh restart n’a pas eu d’effet non plus.

Voilà ce que donne ssh :

OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/arofarn/.ssh/config
debug1: /home/arofarn/.ssh/config line 11: Applying options for git.arofarn.info
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to git.arofarn.info [82.64.151.228] port 22.
debug1: Connection established.
debug1: identity file /home/arofarn/.ssh/id_ed25519 type 3
debug1: identity file /home/arofarn/.ssh/id_ed25519-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 git.arofarn.info:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp521
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-nistp521 SHA256:B5Umy0NDmRIyKrU8GOM7KwdVXNc4wWyAhg2rOrWybvo
debug1: Host 'git.arofarn.info' is known and matches the ECDSA host key.
debug1: Found key in /home/arofarn/.ssh/known_hosts:1
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/arofarn/.ssh/id_ed25519 ED25519 SHA256:Kk10Jn8PRAGTSQ1blMO7WWLllxJMkAfLLGqeF6f0yPM explicit agent
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
debug1: Next authentication method: publickey
debug1: Offering public key: /home/arofarn/.ssh/id_ed25519 ED25519 SHA256:Kk10Jn8PRAGTSQ1blMO7WWLllxJMkAfLLGqeF6f0yPM explicit agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
git@git.arofarn.info: Permission denied (publickey).

J’ai tout repris depuis le début à tête reposée et pas de changements. J’ai re-revérifié sshd_config et le paramétrage de GitLab (admin et user) et je ne vois pas ce qui peut clocher :confused:

Un reboot complet du serveur n’y fait rien non plus.

Est-ce que tu es sur que cet utilisateur est autorisé à se logger en ssh …

A priori oui:

  • j’ai ajouté une directive “AllowUsers admin git” à /etc/sshsshd_config pour m’en assurer explicitement.
  • l’utilisateur admin qui se logue bien sur maison.arofarn.info, n’y arrive pas plus que git sur git.arofarn.info
  • contrairement à admin, l’utilisateur git n’arrive pas à se loguer peut importe l’adresse utilisée (git., maison. ou IP local).

Je comprends pas comment ca pourrait etre different en fonction du domaine si c’est la meme machine … Les deux domaines pointent bien vers la meme IP ?

Oui, les 2 domaines pointes vers la même IP redirigée vers la même machine sur laquelle est installée yunohost avec les différents services.

C’est un des points que je ne comprend pas trop en fait.

Les interfaces web fonctionnent d’ailleurs correctement avec gitlab sur git.arofarn.info et le reste sur maison.arofarn.info.

Je viens de résoudre un premier problème.

Apparement, malgré la clef saisie dans l’interface de gitlab, le fichier authorized_keys de l’utilisateur git était vide.
J’ai ajouté la clef publique manuellement et maintenant ça passe :slight_smile:

Note : le home (où on trouve .ssh/authorized_keys) de git est dans /var/opt/gitlab

Au passage j’ai compris pourquoi admin n’arrive pas à se loguer en SSH via git.arofarn.info : comme j’ai défini une paire de clefs SSH spécifiques pour gitlab et que j’ai défini ces clefs pour git.arofarn.info, il fallait que j’ajoute aussi ces clefs l’authorized_keys d’admin. :expressionless:

Maintenant, git arrive à établir une connexion SSH mais un dernier problème me barre encore la route:

$ git push -v --set-upstream git@git.arofarn.info:arofarn/projet master
Poussée vers git@git.arofarn.info:arofarn/projet
fatal: 'arofarn/projet' does not appear to be a git repository
fatal: Impossible de lire le dépôt distant.

Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.```

Vraie solution finale :slight_smile:

Il n’y pas besoin de modifier manuellement le fichier /var/opt/gitlab/.ssh/authorized_keys.

Pour une raison que je ne comprend pas encore, après avoir ajouter la clef SSH dans mon profil utilisateur le fichier /var/opt/gitlab/.ssh/authorized_keys n’a pas été mis à jour.

J’ai trouvé comment forcer cette mise à jour avec la commande:
$ sudo gitlab-rake gitlab:shell:setup

Source : problème similaire par là => https://gitlab.com/gitlab-org/gitlab/-/issues/2882
Doc officielle :
https://docs.gitlab.com/ee/administration/raketasks/maintenance.html#rebuild-authorized_keys-file

Reste que Gitlab continue de ne pas mettre à jour le fichier authorized_keys (testé avec une autre clef)

EDIT : c’est un problème de GitLab connu et déjà rapporté à GitLab


avec une solution proposée : https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27798

Le problème n’était donc pas dans la config. de yunohost

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.