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 : tout d'abord, vous vous assurez que vous pouvez vous connecter directement au serveur distant et à Bitbucket à l'aide de votre clé SSH. Vous démarrez ensuite l'agent SSH sur votre machine locale avec eval `ssh-agent -s` et stockez votre clé actuelle avec ssh-add -k . Désormais, avec le transfert d'agent activé, vous vous connectez au serveur distant via ssh -A username@host1 et pouvez ensuite accéder à votre référentiel Bitbucket sans autre demande de mot de passe et sans avoir à y stocker la clé SSH du serveur distant.
Une autre alternative consiste à passer à un fournisseur complètement différent : GitLab, par exemple, propose déjà des clés de déploiement dans le plan gratuit en plus d'un quota de 10 Go (contre 2 Go avec Bitbucket) et d'un nombre illimité de membres de l'équipe. Cela vous permet de stocker n'importe quel nombre de clés SSH supplémentaires (par exemple provenant du serveur de production) individuellement pour chaque référentiel, qui accordent des droits d'écriture au référentiel.