Clés Bitbucket et SSH

Le fournisseur Bitbucket (même dans les tarifs payés Standard et Premium) n'offre pas la possibilité de stocker des clés SSH avec des droits d'écriture au niveau du référentiel. Le stockage de votre clé SSH personnelle sur le serveur de production n'est pas une option, car sinon vous pouvez accéder à tous les autres projets sur lesquels vous travaillez actuellement. Il existe ce qu'on appelle des clés d'accès , mais celles-ci ne permettent qu'un accès en lecture.


Si vous développez localement sur un projet puis intégrez ce référentiel sur un serveur de production avec un accès en écriture, il y a deux options: soit vous créez votre propre utilisateur (sous licence et payant à partir de 5 utilisateurs) soit vous l'utilisez le transfert d'agent SSH plutôt inconnu.

Avec cette procédure, vous pouvez réutiliser votre clé SSH locale sur un serveur distant dans la session en cours sans avoir à y stocker définitivement la clé. La configuration est simple: assurez-vous d'abord que vous pouvez vous connecter directement au serveur distant et à Bitbucket à l'aide de votre clé SSH. Ensuite, vous démarrez l' agent SSH sur votre machine locale avec eval `ssh-agent -s` et enregistrez votre clé actuelle avec ssh-add -k . Vous vous connectez maintenant au serveur distant avec le transfert d'agent activé via ssh -A username @ host1 et pouvez ensuite accéder à votre référentiel Bitbucket sans autre mot de passe, sans avoir à y stocker la clé SSH du serveur distant.

Une autre alternative est de passer à un fournisseur complètement différent: GitLab, par exemple, offre un quota gratuit de 10 Go (contre 2 Go pour Bitbucket), un nombre illimité de membres de l'équipe et des clés dites de déploiement . Cela signifie que vous pouvez stocker autant de clés SSH supplémentaires (par exemple depuis le serveur de production) que vous le souhaitez pour chaque référentiel, ce qui accorde un accès en écriture au référentiel.

Arrière