1 votes

Clone Git via SSH : accès refusé uniquement depuis un serveur spécifique

J'ai un serveur Ubuntu 12.04 dans le réseau de mon bureau qui est utilisé pour héberger nos dépôts Git. Le serveur exécute Gitlab 7.1.1 et dispose de SSH sur un port non standard.

Il fonctionne parfaitement pour tout le monde à l'intérieur et à l'extérieur du réseau du bureau, à une exception près. Cette exception est un serveur géré par une société d'hébergement, je n'y ai donc qu'un accès limité.

Lorsque j'essaie de cloner le dépôt sur le port non standard, le processus est interrompu. Je suppose que c'est parce que le port sortant est bloqué par la société d'hébergement. Pour résoudre ce problème, j'ai configuré la redirection de port sur le routeur de mon bureau pour rediriger le trafic entrant sur le port 22, vers mon port non standard sur le serveur git. J'ai testé en clonant depuis un VPS Digial Ocean sans spécifier le port, et cela a bien fonctionné.

Mais le serveur problématique donne maintenant l'erreur suivante :

Access denied.
fatal: The remote end hung up unexpectedly

Le serveur git enregistre l'établissement d'une connexion SSH et accepte la clé publique, comme le montre l'image suivante /var/log/auth.log :

Jan 20 15:09:07 gitlab sshd[3043]: Accepted publickey for git from 10.0.1.254 port 60771 ssh2
Jan 20 15:09:07 gitlab sshd[3043]: pam_unix(sshd:session): session opened for user git by (uid=0)
Jan 20 15:09:09 gitlab sshd[3162]: Received disconnect from 10.0.1.254: 11: disconnected by user
Jan 20 15:09:09 gitlab sshd[3043]: pam_unix(sshd:session): session closed for user git

Cela ne semble pas différent de toute autre demande d'authentification dans le journal, donc je n'ai aucune idée de la raison pour laquelle le clone échoue ?

J'ai installé un dépôt de test sur Github, et le serveur problématique se clone bien par SSH. Il a juste un problème avec les dépôts de mon serveur de bureau par SSH pour une raison quelconque.

Il est également intéressant de noter que le serveur problématique peut cloner par HTTP avec un nom d'utilisateur et un mot de passe sans problème, c'est seulement par SSH que le problème se pose.

Vous avez une idée de ce qui se passe ici ?

PS, je suis plus un codeur qu'un administrateur de serveur, je m'implique dans ce projet pour essayer d'améliorer le processus de déploiement de mon entreprise, donc beaucoup de choses sont nouvelles pour moi.

1voto

shauno Points 21

J'ai résolu ce problème.

Le problème était que la clé publique du serveur problématique avait déjà été ajoutée en tant que "clé de déploiement" à Gitlab pour des tests antérieurs sans rapport. Elle a ensuite été supprimée en tant que clé de déploiement, mais pour une raison quelconque, la clé a persisté dans la base de données de Gitlab. Gitlab m'a ensuite permis de réattribuer la même clé à un utilisateur de test sans se plaindre qu'elle existait déjà ailleurs dans la base de données. Mais lorsque j'essayais de m'authentifier avec cette clé, Gitlab recherchait la clé et obtenait la première clé "orpheline", de sorte qu'il ne donnait qu'un accès anonyme, ce qui ne permettait évidemment pas le clone.

Pour résoudre le problème, j'ai trouvé l'id de la clé orpheline, et je l'ai supprimé avec la commande git-Shell :

./bin/gitlab-keys rm-key key-21

21 était l'ID de la clé orpheline.

Tout fonctionne maintenant comme prévu.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X