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.
Cette méthode vous permet de réutiliser votre clé SSH locale sur un serveur distant au sein de la même session, sans avoir à la stocker définitivement. La configuration est simple : assurez-vous d'abord 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 ajoutez votre clé actuelle avec `ssh-add -k` . Connectez-vous ensuite au serveur distant avec le transfert d'agent activé en utilisant `ssh -A username@host1`. Vous pourrez alors accéder à votre dépôt Bitbucket sans avoir à saisir de mot de passe et sans avoir à stocker 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.