• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      It would be very helpful to have shared ssh credentials like jenkins has
      We are deploying to testing / staging and production servers via scp and run a view tasks (service restarts, etc) via ssh afterwards
      If you could configure ssh credentials for these servers globally and re-use them in your jobs it would save you from editing multiple jobs if the credentials or the server changes.

          Form Name

            [BAM-14860] Shared credentials for SCP / SSH Task

            online1 how AWS shared credentials can be used in SSH/SCP task?

            Alexey Chystoprudov added a comment - online1 how AWS shared credentials can be used in SSH/SCP task?

            +1 especially using aws shared credentials.

            Neocreative Admin added a comment - +1 especially using aws shared credentials.

            +1

            I agree with Jorg. It is important feature.

            I have 10,25,100,250 agents but destinations servers I have about 1500 and more.

            I can;t install on all destinations servers agents because:

            • Not exist tier 1500 agents
            • Cost will be big! ( 250 agents is very expensive )

            I only can use agents and connect to destination servers by SSH TASK or SCRIPT TASK

            if I have login/pass/key or something in password manager ( creditential manager ) and I can decide witch plan can use this data it will be super elastic for me.

            I have FOUR UAT env, 2 SIT, 3 TEST.

            I have 1 deploy plan for env ( 4+ 2+ 3 = 9 deploy plans ).

            In this scenario I have one user to "deploy" on this NINE environments.

            Now I must "reedit" 9 deploy plans with all task in it to change password to new.

            In Jenkins - Jenkins have creditentials manager and that is it.

            Meybe on SMALL environment about 10-100 servers, 1 AGENT per SERVER - is ok. 

            But if Bamboo want to be a enterprise product - not now with many stoppers and lack of functionality used in enterprise environment.

            Sorry for my language  

            rgs

            Maciek

             

             

            Ląd Maciej - PZU added a comment - I agree with Jorg. It is important feature. I have 10,25,100,250 agents but destinations servers I have about 1500 and more. I can;t install on all destinations servers agents because: Not exist tier 1500 agents Cost will be big! ( 250 agents is very expensive ) I only can use agents and connect to destination servers by SSH TASK or SCRIPT TASK if I have login/pass/key or something in password manager ( creditential manager ) and I can decide witch plan can use this data it will be super elastic for me. I have FOUR UAT env, 2 SIT, 3 TEST. I have 1 deploy plan for env ( 4+ 2+ 3 = 9 deploy plans ). In this scenario I have one user to "deploy" on this NINE environments. Now I must "reedit" 9 deploy plans with all task in it to change password to new. In Jenkins - Jenkins have creditentials manager and that is it. Meybe on SMALL environment about 10-100 servers, 1 AGENT per SERVER - is ok.  But if Bamboo want to be a enterprise product - not now with many stoppers and lack of functionality used in enterprise environment. Sorry for my language   rgs Maciek    

            I agree on the last comment that rotating a key causes security and maintainability issues.

            Nico Knaepen added a comment - I agree on the last comment that rotating a key causes security and maintainability issues.

            I usually recommend others to avoid the SSH bamboo task due to lack of shared credentials.
            While it means that every build running on that agent could potentially use or view this SSH key, passing this key around to all developers editing the builds, or even the inability to rotate the keys makes the SSH task worse in security and maintainability.

            Cintia Calvo added a comment - I usually recommend others to avoid the SSH bamboo task due to lack of shared credentials. While it means that every build running on that agent could potentially use or view this SSH key, passing this key around to all developers editing the builds, or even the inability to rotate the keys makes the SSH task worse in security and maintainability.

            Jörg Wartenberg, you can configure native SSH from your remote agents to those test boxes, and use native ssh command straightaway (from a bash/script bamboo task) instead of the SSH task.

            That's what I would recommend anyway in order to even be able to rotate the keys every so often.

            Cintia Calvo added a comment - Jörg Wartenberg, you can configure native SSH from your remote agents to those test boxes, and use native ssh command straightaway (from a bash/script bamboo task) instead of the SSH task. That's what I would recommend anyway in order to even be able to rotate the keys every so often.

            This is very important for us, because we have to execute all our test cases via SSH and not only some deployment tasks. Our test cases have to be executed on a third party system with given Linux OS version, which isn't support by recent JAVA versions.Therefore we can't execute the remote agent on it and need to use SSH calls to execute the testcases.

            The test cases should be configured by several engineers and we wouln't like to give all of them the private SHH credentials.

            Jörg Wartenberg added a comment - This is very important for us, because we have to execute all our test cases via SSH and not only some deployment tasks. Our test cases have to be executed on a third party system with given Linux OS version, which isn't support by recent JAVA versions.Therefore we can't execute the remote agent on it and need to use SSH calls to execute the testcases. The test cases should be configured by several engineers and we wouln't like to give all of them the private SHH credentials.

            jmo added a comment -

            Is there a reason shared credentials are available to other parts of Bamboo (like repos), but not deployment tasks?

            jmo added a comment - Is there a reason shared credentials are available to other parts of Bamboo (like repos), but not deployment tasks?

            I still can't believe that this isn't there.  

            Ideally there would be some access control built in, so that, e.g., not every bamboo user has access to the ssh keys for the production servers. 

            icpsr-licenses added a comment - I still can't believe that this isn't there.   Ideally there would be some access control built in, so that, e.g., not every bamboo user has access to the ssh keys for the production servers. 

              achystoprudov Alexey Chystoprudov
              e4eb8ba93c32 Caroline Chan
              Votes:
              79 Vote for this issue
              Watchers:
              66 Start watching this issue

                Created:
                Updated:
                Resolved: