Dostawca Bitbucket nie oferuje (nawet w płatnych Standard i Premium taryf ) możliwość przechowywania kluczy SSH z uprawnieniami zapisu na poziomie repozytorium. Przechowywanie osobistego klucza SSH na serwerze produkcyjnym nie jest opcją, w przeciwnym razie możesz uzyskać dostęp do wszystkich innych projektów, nad którymi aktualnie pracujesz. Istnieją tak zwane klucze dostępu , ale umożliwiają one tylko odczyt.
Więc jeśli tworzysz lokalnie w projekcie, a następnie integrujesz to repozytorium na serwerze produkcyjnym z dostępem do zapisu, istnieją dwie opcje: albo utworzysz własnego użytkownika (licencjonowanego i dla 5 lub więcej użytkowników) do tego celu, albo możesz go użyć raczej nieznane przekazywanie agentów SSH .
Dzięki tej procedurze możesz ponownie użyć lokalnego klucza SSH na zdalnym serwerze w bieżącej sesji bez konieczności trwałego przechowywania tam klucza. Konfiguracja jest prosta: Najpierw upewnij się, że możesz połączyć się bezpośrednio zarówno ze zdalnym serwerem, jak i Bitbucketem, używając klucza SSH. Następnie uruchamiasz agenta SSH na komputerze lokalnym za pomocą eval `ssh-agent -s` i przechowujesz bieżący klucz za pomocą ssh-add -k . Teraz, gdy włączone jest przekazywanie agentów, łączysz się ze zdalnym serwerem przez ssh -A nazwa_użytkownika@host1 i możesz uzyskać dostęp do repozytorium Bitbucket bez dalszego pytania o hasło i bez konieczności przechowywania tam klucza SSH serwera zdalnego.
Inną alternatywą jest przejście do zupełnie innego dostawcy: na przykład GitLab oferuje już w darmowym planie tzw. klucze wdrażania oprócz limitu 10 GB (w porównaniu do 2 GB w przypadku Bitbucket) i nieograniczonej liczby członków zespołu. Dzięki temu można przechowywać dowolną ilość dodatkowych kluczy SSH (np. z serwera produkcyjnego) indywidualnie dla każdego repozytorium, które przyznają prawa zapisu do repozytorium.