Month: June 2013

Everyone knows that passwords aren’t always secure, annoying to remember and type. Add to that the longer/stronger your password the harder it is to remember. Therefore ssh-keys are very convenient and more secure. However, most people don’t put a passphrase on their ssh-keys because surely this would mean you would have to enter this passphrase every time you use the key and therefore remove the whole convenience of the key.

Ubuntu (and most versions of linux) come with a handy tool (ssh-agent) which can store your passphrase securely and enter it for you when you login. Essentially, this post really is a quick guide to using ssh-agent on Ubuntu.

Here are the commands you need.

1 – Generate a ssh-key

$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/user/.ssh/id_rsa):

Enter passphrase (empty for no passphrase): [Type a passphrase]

Enter same passphrase again: [Type passphrase again]

........

.......

2 – Add the ssh-key to your ssh-agent!

$ ssh-add

Enter passphrase for /home/user/.ssh/id_rsa:

Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

3 – Copy the ssh to your remote host

$ssh-copy-id user@remote.com

user@remote.com's password:

.....

4 – Now ssh in… look no passphrase required!

$ ssh user@remote.com

There are also a handy gui tool for adding and removing stored keys. It’s called Seahorse but you can find it by typing “passwords” or “keys” into dash search.

You can install Balsamiq Mockup on Linux / Ubuntu but Balasmiq don’t provide good instructions. I have no idea why they don’t spend a little time and write documentation properly. Anyhow, here is how I installed Balsamiq on my Ubuntu 13.04 laptop.

The Ansible website has some instructions for installing it on Ubuntu here. However, I like to install things from repositories and not git. So, I found a PPA with the latest version of Ansible on Launchpad.

We have been using both Puppet and Ansible to configure our servers for several months. I have come to really love Ansible and I wanted to put down my reasons for finally choosing Ansible over Puppet.

Reason 1: Ansible is decentralised. With Puppet you need to maintain a central configuration server and install a Puppet Client (with root permissions) on each machine that you wish to configure. These individual client machines then connect to the configuration server and pull down their configurationa. Personally, as much as I love servers, I don’t want to maintain another server and client software. Ansible doesn’t require any central server. You just install and run it on your local machine. It doesn’t have any client software and configures the machines over ssh. This allows you to configure computers from anywhere, at anytime from any computer which has Ansible installed. This decentralised approach also means that Ansible once has done the configuration – it doesn’t sit there running in the background using power etc.

Reason 2: Ansible instantantly configures and provides feedback. . Puppet is based on a pull system which means the client ‘polls’ the server for changes to configurations. This means that there is a lag between writing a new configuration and having it pulled down to a server. For me this seem too complicated. Once I have written a configuration – I want to push it out immediately and check it worked.

Reason 3: Ansible configurations are ordered
Ansible is a little like a scripting language with commands running in a structured and ordered manner. Puppet on the other hand makes it hard to run ordered commands. It is possible by using dependencies. However, the simplicity of Ansible is, well, much simplier.

Reason 4: Ansible has a much gentler learning curve
It took me a much shorter period of time to learn Ansible compared to Puppet and achieve the same results. I’ve also found that it is much easier to explain Ansible to other people that I work with. For example – I’ve developed an Ansible script which configures a new development enviroment for an application that our team is working on. One of the members of the team saw the script in the repository and used it to configure his development enviroment with no prior knowledge of Ansible after 5 minutes of explaination from me. I’m sure that the reason for this is because Ansible script looks like other types of scripts and sysadmins and developers easierly understand scripts.