La provizanto Bitbucket ne ofertas (eĉ en la tarifaj normaj kaj superaj tarifoj ) la eblon stoki SSH-ŝlosilojn kun skriba aliro ĉe la deponeja nivelo. Konservi vian personan SSH-ŝlosilon sur la produkta servilo ne estas eblo, alie vi povas aliri ĉiujn aliajn projektojn, pri kiuj vi nun laboras, de tie. Estas tiel nomataj alirŝlosiloj , sed ĉi tiuj nur permesas legrajtojn.
Do, se vi disvolviĝas loke en projekto kaj poste integras ĉi tiun deponejon en produkta servilo kun skriba aliro, estas du ebloj: Aŭ vi kreas vian propran uzanton (por esti rajtigita kaj por 5 aŭ pli da uzantoj) por ĉi tiu celo, aŭ vi povas uzi ĝin la sufiĉe nekonata SSH-agento plusendanta .
Kun ĉi tiu proceduro, vi povas reuzi vian lokan SSH-ŝlosilon sur fora servilo en la nuna sesio sen devi konstante konservi la ŝlosilon tie. La aranĝo estas simpla: Unue, vi certigas, ke vi povas konekti rekte al ambaŭ la fora servilo kaj Bitbucket per via SSH-ŝlosilo. Vi tiam lanĉu la SSH-agenton sur via loka maŝino per eval `ssh-agent -s` kaj konservu vian nunan ŝlosilon per ssh-add -k . Nun, kun agenta plusendado aktivigita, vi konektas al la fora servilo per ssh -A uzantnomo@gastiganto1 kaj tiam povas aliri vian Bitbucket-deponejon sen plia pasvorta instigo kaj sen devi stoki tie la SSH-ŝlosilon de la fora servilo.
Alia alternativo estas ŝanĝi al tute alia provizanto: GitLab, ekzemple, jam ofertas tiel nomatajn deplojajn ŝlosilojn en la senpaga plano krom kvoto de 10 GB (kompare kun 2 GB kun Bitbucket) kaj senlima nombro da teamanoj. Ĉi tio permesas vin konservi ajnan nombron da kromaj SSH-ŝlosiloj (ekz. de la produktadservilo) individue por ĉiu deponejo, kiuj donas skribrajtojn al la deponejo.