Command Center SSH Bitbucket

Connecting Command Center to Bitbucket using SSH

Background

Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using SSH. This type of connection is not possible via the Custom Git Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.

Process Overview

• Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)
• Creation of a pub/private key in the Command Center Container
• Adding the public key to Bitbucket Cloud Repository
• Adding three custom scripts to the GitHub Repo
• Creating a Custom Data Source in Command Center to access the three scripts
• Leveraging the Custom Data Source from the desired Command Center Project

Additional Notes

Although this page details the process for Bitbucket, the same technique can be applied to other repositories such as GitLab as well. The overall process would be the same.

GitHub Repository Initial Setup

Create a new repository in GitHub that will be used for storing the three custom scripts.

• Create top level directory for storing the scripts
• This directory will contain the following three scripts as described later in the document.
  • clone.sh
  • pull.sh
  • pushfiles.sh

Bitbucket Cloud Repository Configuration

Command Center Container

The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.

• Perform this within the container itself for Command Center
• Do not add a password to the key pair when prompted
• The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.
• You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions

Follow the below command after logging into the VM and then logging into the Command Center container as the root user.

   root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser
   Changing the login shell for tomcatuser
   Enter the new value, or press ENTER for the default
         Login Shell [/sbin/nologin]: /bin/bash
   su - tomcatuser
   ssh-keygen -t rsa -b8192
   Generating public/private rsa key pair.
   Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):
   Creating directory /usr/local/tomcat/.ssh
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa
   Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub
   The key fingerprint is:
   SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55
   The key's randomart image is:
   +---[RSA 8192]----+
   |        . o o... |
   |         = +.+. .|
   |      . . X ==oo |
   |       * = Xo=+ E|
   |      o S = *o . |
   |       . = o.o   |
   |        . o ..   |
   |           o=..  |
   |          .+=B.  |
   +----[SHA256]-----+

Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.

Bitbucket Cloud Repo

Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.

• Click on Settings Icon to left of the User Icon
• Select SSH Keys in the left column
• Click on Add Key
• Provide a label as appropriate
• Paste the public key (Be sure it's the public key!)
  • In this example it is id_rsa.pub
• Select Add key and the key should be listed as available
  • Confirm the key has r/w access to the repo as noted in the next section

Command Center Container

Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.

   cd /tmp/
   git clone git@bitbucket.org:<username>/<repo>.git
   This key is not known by any other names
   Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
   Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.
   exit (returns you to root user)
   chsh tomcatuser
   Changing the login shell for tomcatuser
   Enter the new value, or press ENTER for the default
         Login Shell [/bin/bash]: /usr/sbin/nologin

At this point the key has been validated in Bitbucket as working.

NOTE: At this point you have a working SSH key for Bitbucket. It's important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs

Script Additions to GitHub Repository

Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.

• clone.sh
  • Requires the following to be updated
    • REPO - Obtain this path from the repository itself, there is normally a link that can be clicked to copy the path
    • BRANCH_NAME
• pull.sh
  • Requires the following to be updated
    • BRANCH_NAME
• pushfiles.sh
  • No modifications are required in this script.

clone.sh

   **Be sure to supply the USER_NAME, REPO, BRANCH where indicated**
   
       #!/bin/bash
       
       REPO="ssh://git@bitbucket.org/<REPO>.git"
       BRANCH="<BRANCH_NAME>"
       
       echo "Using credential: ${CREDENTIAL_NAME}"
       
       echo "=================================================================="
       echo "Custom Clone Incoming variables:"
       echo ""
       echo "     CUSTOM_DIR      = ${CUSTOM_DIR}"
       echo "     WORKSPACES_DIR  = ${WORKSPACES_DIR}"
       echo "     WORKSPACE_NAME  = ${WORKSPACE_NAME}"
       echo "     REPO = ${REPO}"
       echo "     BRANCH = ${BRANCH}"
       
       echo "User running git clone is $(whoami)"
       
       # For Debugging
       GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"
       ret=$?
       echo "Clone return status $ret"
       if [ $ret -ne 0 ] ; then
          exit 1
       fi
       
       # This use case only occurs when a clone was done prior and the branch was different from the desired one
       cur_branch="$(git rev-parse --abbrev-ref HEAD)"
       
       if [ "${cur_branch}" != "${BRANCH}" ] ; then
           echo "Branch was ${cur_branch} so switching to ${BRANCH}"
           git switch "${BRANCH}"
       else
           echo "Branch already at ${cur_branch}, no need to switch "
       fi
       
       cd ~/ || exit 1
       
       exit 0

pull.sh

   **Be sure to supply the branch where indicated**
   
       #!/bin/bash
       
       BRANCH="<BRANCH_NAME>"
       
       echo "Using credential: ${CREDENTIAL_NAME}"
       echo "=================================================================="
       echo ""
       echo "Custom Pull Incoming variables:"
       echo "     CUSTOM_DIR         = ${CUSTOM_DIR}"
       echo "     CLIENT_SOURCE_DIR  = ${CLIENT_SOURCE_DIR}"
       echo "     BRANCH = ${BRANCH}"
       
       echo "User running git pull is $(whoami)"
       
       # For Debugging
       cd "${CLIENT_SOURCE_DIR}" || exit 1
       GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull
       ret=$?
       echo "Pull return status $ret"
       if [ $ret -ne 0 ] ; then
          exit 1
       fi
       
       # This use case only occurs when a clone was done prior and the branch was different from the desired one
       cur_branch="$(git rev-parse --abbrev-ref HEAD)"
       
       if [ "${cur_branch}" != "${BRANCH}" ] ; then
           echo "Branch was ${cur_branch} so switching to ${BRANCH}"
           git switch "${BRANCH}"
       else
           echo "Branch already at ${cur_branch}, no need to switch "
       fi
       
       cd ~/ || exit 1
       
       exit 0

pushfiles.sh

       #!/bin/bash
       echo "Using credential: ${CREDENTIAL_NAME}"
       
       echo "=================================================================="
       echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"
       echo ""
       echo "Custom Push Files Incoming variables:"
       echo "     CUSTOM_DIR        = ${CUSTOM_DIR}"
       echo "     CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"
       echo "     IMPORT_MESSAGE    = ${IMPORT_MESSAGE}"
       echo "     IMPORT_LIST_PATH  = ${IMPORT_LIST_PATH}"
       
       echo "User running pushfiles is $(whoami)"
       
       # run script
       cd "${CLIENT_SOURCE_DIR}" || exit 1
       echo "Files to import to the repo are: "
       cat "${IMPORT_LIST_PATH}"
       while IFS= read -r f; do
           git add "$f"
           ret=$?
           echo "Push add status $ret"
           if [ $ret -ne 0 ] ; then
               exit 1
           fi
       done < "${IMPORT_LIST_PATH}"
       git commit -m "${IMPORT_MESSAGE}"
       GIT_SSH_COMMAND="ssh" git push 
       ret2=$?
       echo "Push return status $ret2"
       if [ $ret2 -ne 0 ] ; then
          exit 1
       fi
       
       cd ~/ || exit 1
       
       exit 0

Create a new Custom Data Source

Once the scripts have been created and placed into the GitHub repository, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source

• When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.
• There will be one Custom Data source created for a single repo/branch used by Command Center
  • If two branches from the same repository are required, there will be two Custom Data Sources Required.

Leveraging the Custom Data Source from Command Center

At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file.