How to Use the SSH Tool
Toshi Dávila avatar
Written by Toshi Dávila
Updated over a week ago

What is the SSH tool?

It's a universal tool that can run virtually any command on a remote server over SSH. Add tasks to run with the click of a button or trigger tasks on time-based events like hourly, daily, or when events happen such as commits or created merge requests within your repositories.

The SSH tool can provide comfort to Operations teams by standardizing common jobs that run on mission critical servers. With the SSH tool, you do not have to rely on team members to set up SSH, be able to run things via command line, or risk human error. Once configured, any team members with permission can use it and you’ll know actions will be performed with 100% certainty.

Not only is configuring the SSH tool more convenient than running the command in a terminal window, but it provides accountability and logging so you can see who performed the action and when, see a log of what happened, and see the result of the action (pass or fail).

What is the SSH tool useful for?


While Assembla’s FTP deploy tool is great, it has its limits. With a little extra work, the SSH tool functions as a flawless deploy tool no matter how complicated your setup might be.

If you already use a tool like Capistrano or have automated your application's deploy process on the command line, you are most of the way there. Just add your server to the SSH tool, configure authentication, and add the command.

If your deploy process is more complicated than sending files to a server, and you don’t have a script that deploys your application, we highly recommend you look into creating one. Once you have a working script, hooking it up to the SSH tool will be easy.

Other Maintenance Tasks

We have used the SSH tool internally or seen our customers use it for:

  • Deploying to multiple environments (eg staging, QA, production)

  • Restarting services (memcached, leaky webapps, etc.)

  • Rolling a deploy back to a previous version

  • Synchronizing a path on remote server(s) with version control

How to Configure the SSH tool

1. Install the SSH tool: If your project does not have the SSH tool as a tab, you can install it by visiting the Admin tab of your project, clicking on the Tools section, and then clicking the Add button next to SSH.

2. Configure a server: Add a name and description for your server, its hostname or IP address, and the port that it runs SSH on. Normally this will be port 22.

3. Download the DSA key and configure a user on your server: Download the DSA key from Assembla, and choose or create a user on your server that will be used to perform the tasks. Place the key into your user's authorized_keys file. Usually this will be /home/<USER>/.ssh/authorized_keys, but you may need to create the .ssh/ directory.

4. Create a script: Once a server is configured, you can click on the ‘New Script’ submenu option and configure the script. You can use the variables #SPACENAME# and #USERNAME# here, and they will be replaced by the name of the space and the user running the command respectively.

5. Once the server and script have been added, you are ready to rock and roll.

Advanced Tip: Assembla’s API can control the SSH tool with the same capabilities as the web interface so you can incorporate the SSH tool with 3rd party applications using the API.

How we streamlined our deploy process at Assembla with the SSH tool

All of our production deploys now happen through the SSH tool which has streamlined the process dramatically. We use Capistrano and have for a long time, but we used to need a member of the operations team to run Capistrano manually whenever a developer needed to deploy.

The old process was a burden on the developers and the Operations team, especially when we started deploying 10+ times a day. The old process usually went like this:

  • A developer would ask in the main chat room "Any ops around for a deploy?"

  • Ops would respond and might have a quick chat with the dev before the code to deploy would be merged

  • Ops would then announce in the chat  "Deploying.." and kick off the deploy manually

  • Ops would monitor the output from the deploy script and paste a url into the chat showing the changeset of what was just deployed

  • Then finally announce "Deploy done!"

Once we had the SSH tool in place, devs took on most of these tasks. They would still ask if operations staff were present just in case something went wrong. This was a huge time saver and removed much of the burden. It was now up to the dev doing the deploy to announce and paste the changeset URL. It still wasn't as good as it could be, so we improved it again.

We got rid of "Any ops around?" by building a step into the deploy script that looks for the status of operations staff on chat networks, and if all were in an "away" status, the deploy would fail.

Then, we made the SSH tool actions and merge request features accessible from the API and wrote a Hubot script for our bot named “jenks.” 

Here's what a typical deploy looks like now:

So one quick request in chat will kick off a deploy, keep the team updated, and let us know when it is done with a full report. Now that is service with a [virtual] smile.

If you have any questions or need our assistance, don't hesitate to contact us at 

Did this answer your question?