Clés Bitbucket et SSH

Le fournisseur Bitbucket n'offre pas (même dans les tarifs Standard et Premium payants ) la possibilité de stocker des clés SSH avec 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, sinon vous pouvez accéder à tous les autres projets sur lesquels vous travaillez actuellement à partir de là. Il existe des soi-disant clés d'accès , mais celles-ci n'autorisent que des droits de lecture.


Ainsi, si vous développez localement sur un projet puis intégrez ce référentiel sur un serveur de production avec accès en écriture, il y a deux options: Soit vous créez votre propre utilisateur (à licencier et pour 5 utilisateurs ou plus) à cet effet, soit vous pouvez l'utiliser 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: vous devez d'abord vous assurer de pouvoir vous connecter directement au serveur distant et à Bitbucket à l'aide de votre clé SSH. Ensuite, démarrez l' agent SSH sur votre machine locale avec eval `ssh-agent -s` et stockez votre clé actuelle avec ssh-add -k . Avec le transfert d'agent activé, vous pouvez maintenant vous connecter au serveur distant via ssh -A username @ host1 , puis accéder à votre référentiel Bitbucket sans avoir à y entrer la clé SSH du serveur distant.

Une autre alternative est de passer à un fournisseur complètement différent: GitLab, par exemple, propose déjà un quota de 10 Go (contre 2 Go avec Bitbucket) ainsi qu'un nombre illimité de membres de l'équipe et des clés dites de déploiement au tarif gratuit. Cela signifie que n'importe quel nombre de clés SSH supplémentaires (par exemple à partir du serveur de production) peut être stocké dans chaque référentiel, ce qui accorde un accès en écriture au référentiel.

Retour