New Blog Direction – Flutter Mobile Development

It has been ~10 months since my last post… In that time I have started a new job, bought a house, learned great amount of new skills at my new job (one of which is mobile development), I’ve created and released my own Xamarin app called Prog and finally… Contributed (currently an open pull request) to my first open source project ever – Flutter Camera Plugin.

It’s safe to say that this last year (2018) has been quite the roller-coaster, and has led me away from Raspberry Pi development. I believe my interest in this technology had peaked when I saw my code interacting with live machinery via the Pi in my previous employment. Since then, I have not had any project worth investing time into with regards to the Raspberry Pi. Therefore, this blog is taking a new direction – Mobile Development.


My first entry into mobile development was using Xamarin Forms 3.0. While I did battle through and eventually release my own app, I don’t think I will be using it again. The eco system on Windows was broken. As an example: making a small change would result in a 5 minute wait for a compile and deployment to take place. If the compile didn’t fail and you didn’t have to restart Visual Studio, clean and rebuild you would just find out that the small change you made didn’t work and you had to repeat the process until it finally ‘worked’.

Flutter is a game changer I mean really… It has hot reload out of the box and works on all major platforms! It can even hot restart when you make logic changes. On my machine, a hot reload will take 800ms, and a hot restart will take 1.2s.

The layout and widget system makes perfect sense and the documentation is great. Animations – something developers usually shy away from – is so simple I can’t wait to post about it. Native Functionality integration is super easy also (until you get to the objective-C / Swift code – but that isn’t Flutter’s issue). And finally, it comes with amazing integration with Visual Studio Code.

Anyhow – I just wanted to make a post to say that there will likely never be anymore Raspberry Pi stuff here. I’m likely going to post solutions to problems I encounter and solve during my time developing mobiles apps with Flutter.

[ Raspberry Pi C ++ ] Push Buttons (Reading GPIO Input)

This post has been long overdue and will bring the GPIO tutorial to a close. We focus here on how to read input from external devices. This tutorial will keep things as basic as possible by using a simple push button.  

Previous Post: Our First LED

The push button used in this tutorial has four prongs/legs and looks as follows: 

Image of push Button
Example of a Push Button


Before we begin, there are two other components we require to complete our circuit… 1x 10kOhm resister and 1x 1kOhm resister 

The 1kOhm resister is simply used to dampen the voltage going from the 3.3V pin directly into the GPIO pin when the button is pressed.  

The 10kOhm resister plays a much more important role and is known as a “pull-down” resistor. It sits between an open (un-pressed) button and ground (GND). A pull-down resister is used to prevent erroneous reading from a GPIO pin on an open circuit. I would recommend to learn more about resistors.

A button in this un-pressed state (with a valid pull-down resister) will yield an input reading of 0 (LOW). 

Then when the button is pushed down, the voltage will flow from the 3.3V pin into the INPUT GPIO pin (whilst continuing through the 1kOhm resister) to give us a reading of 1 (HIGH).  

This is how your circuit should look: 

circuit diagram
Complete circuit diagram of push button with valid resistors


The code for this example is very simple (even more so than lighting up our first LED)

#include <stdio.h>
#include <wiringPi.h>

int main(int argc, char** argv)
    // Intialize the wiringPi Library

	const int INPUT_PIN = 12;
    // Read input on this pin
    pinMode(INPUT_PIN, INPUT);

        // As soon as we dedect an input, log and quit.
        if(digitalRead(INPUT_PIN) == HIGH)
			printf("Button is pressed!\n");	

    // Exit program
    return 0;
Reading GPIO Input with C++ and wiringPi

As always, see here on how to compile and run this code.

The code starts by flagging the pin to be used as an input. Later on we detect it’s reading via the digitalRead() function. This will return HIGH / LOW depending on the buttons pressed state.

The program will exit as soon as a HIGH input is received, shortly after printing that the button was pressed. The circuit between the GPIO pin and the 3.3V pin is compete when you press the button thus resulting in a HIGH read.

Earlier on in this post we talked about a pull-down resistor, and without it we may get erroneous reads through the GPIO pin.

I will leave this as a task to the reader, but I would suggest removing the pull-down resistor and tweaking the code to infinitely check the value of the input and see what happens.

Previous Post: Our First LED

[Programming Design Patterns & Practice] – Introduction

Design Patterns

Programming design patterns is something I’ve wanted to blog about for a while. They are fundamental to being a programmer. Knowing a multitude of design patterns and knowing when to apply them separates the true developers from the “code monkeys.”

For example, I have inherited a project in the past where the initial developer had no concept of architectural patterns. 10 years on and a few more developers later, the underlying codebase had become a mess of different developers doing things ‘their way’. This was more than likely due to a lack of a fundamental structure which should of been in place from the get-go.

Having experienced the work place that the developer had previously been at, deadlines were indeed tight. To make things worse, there was usually more than one project going on at a time. However, It is common place for deadlines to be tight in the Software Development industry, so getting the job done is a key part of the job to keep your employer happy.

This does not mean that all care should be dropped from the code you are writing to ‘get it done’ as getting it done and doing it right are very dissimilar. This is where knowing programming design patterns is key. They really don’t take that much more of your time initially and they will save you and future developers time in the future!

If the initial developer put a system in place for managing the database, front end and business logic (MVC springs to mind); all future developers would likely follow the framework. Thus resulting in a unified codebase with a clear indication of what is going on behind the scenes.

Model View Controller Design Pattern Overview
Model View Controller Design Pattern Overview

Programming Practice

This topic is more of a by-product of knowing your design patterns. Knowing when implementing ‘pattern X’ solves ‘problem Y’ is likely going to lead you to down the path of good programming practice.

However, there are some key principles that should resonate in your head as a programmer, off the top of my head they are:

  • Don’t Repeat Yourself (DRY) – Not duplicating code, reuse code by breaking it up into functions/objects.
  • SOLID – An OOP principle used to help define responsibility for classes. It can be seen as the most fundamental practice a programmer should know when working in an object based language.
  • KISS – Keep It Simple, Stupid – Is a funny one by all means but a very good principle. Don’t over-complicate your classes & functions. Break them down into bitesize pieces and chances are you’ll separate your logic and dependencies in the process.

In the project described earlier, it basically broke all of the above rules. Just to give an indication on how bad things were… There was a .txt file named “code to paste.txt”. Inside of it were about 4 different sections of code that had indeed been copied and pasted around the codebase in numerous locations.

Breaking up code into reusable functions is programming 101 – Don’t Repeat Yourself (DRY)!!

I have not got a set list of the patterns I am intending on blogging about, instead I am just going to write about ones I feel like writing at the time.

Suggested: Raspberry Pi Development in C++

[ Raspberry Pi C ++] Our First LED (Controlling GPIO Output)

For this demonstration we will use an LED and have it blink. This post will not present anything new programming wise, rather it will get you familiar with connecting the GPIO pins to something physical.

Previous Post: Compiling, Linking & Using WiringPi

Next Post: Reading Input With Push Buttons

Connecting the GPIO Pins

The connection is rather simple, all we require is one wire going from an I/O Pin to the negative (-) end of the LED, and another wire from the positive (+) leg of the LED to the ground (GND) pin on the Pi.

If you would like to test that your LED is working before this point, instead of connecting to the GPIO pin, connect it to the 5V pin and your LED should illuminate. 

The following image demonstrates the setup with colour co-ordinated wires.

GPIO connection of single LED and GPIO pins
GPIO Connection of a single LED for the Raspberry Pi

As shown above, the green wire is connected to the negative connection of the LED (A.K.A the Cathode). This green wire is also plugged into GPIO pin number 3. This can become quite confusing as it is known as GPIO2 in the header table but the physical pin number is 3. These references matter in whatever way your code initialises wiringPi. Luckily, by default, wiringPi uses the pin numbers.

Finally, the positive leg of the LED (A.K.A the Anode) is connected to the ground pin to ensure a complete circuit.

Writing the Code

Now that we have the connection setup, we need to write the code to make the LED blink. In the previous tutorial we already looked at writing output to the GPIO pins. We will expand on this with a little additional Linux C++ code to delay the on/off state of the pin to make it blink.

#include <stdio.h>
#include <wiringPi.h>

#include <unistd.h> // Required for Sleep();

int main(int argc, char** argv)
    // Intialize the wiringPi Library

    // LED is connected on pin 3. Ensure
    // this pin is set to be an Output.
    pinMode(3, OUTPUT);

    // Ensure the LED is ON initialitial
    int state = HIGH;

    for(int i = 0; i < 10; i++)
        // Turn on or off depending on state
        digitalWrite(3, state);

        // Toggle to HIGH/LOW output
        state = (state == HIGH) ? LOW : HIGH;

        // Wait 1 second

    // Ensure we turn LED off
    digitalWrite(3, LOW);
    // Exit program
    return 0;
Blinking LED in C++

As this is a very straight forward example, each line in the code is commented accordingly.

Please refer to previous posts on how to compile the code and run it on the Raspberry Pi:

Once your circuit is complete and code compiled, run the program and watch the LED blink 10 times!

All code for these tutorials can be found here over at Github

Previous Post: Compiling, Linking & Using WiringPi

Next Post: Reading Input With Push Buttons

[ Raspberry Pi C ++] GPIO Access : Compiling, Linking & Using WiringPi

Previous Post: Using CMake

Next Post: Our First LED

To allow us access to the GPIO pins of the Raspberry Pi in C++ code, we will use a library known as “WiringPi”. What is nice about this library is that the functions we call are similar to those found in the usual Python examples. This should hopefully make it easier for those coming from Python programming on the Raspberry Pi.

As stated in my overview of C++, third party code usually comes in the form of a shared/static library which you link into your projects code. This is the case for WiringPi!

To acquire the use of a third party library, you normally get it in the form of precompiled binaries or downloading and compiling the source code yourself. What “precompiled binaries” mean, is that someone else has compiled the source code on their Pi/machine and distributed the .a/.so (static/shared library) file via a download medium. Precompiled binaries are usually the go-to way of using libraries on Windows machines. In this example however, we will be download the WiringPi source code and compile it ourselves.

Compiling WiringPi

The first thing you want to do is download the WiringPi source code. To retrieve the latest working copy of Wiring Pi, we will use git to clone the repository. If you are unsure if git is installed, you can run the following:

> sudo apt-get install git

Once git is installed, clone the repository by entering the following

> git clone git://

After a few seconds git will have finished downloading. If you list the contents of the current directory (“ls” command) you will notice a folder named “wiringPi”. Simply change into this directory.

> cd wiringPi

If you list the contents of this directory, there will be a lot of files. The one that we are most interested in is the “build” script. Upon running this script, the compilation of the library will begin and its binaries and header files will be automatically installed into the appropriate /usr/local folders on our system.

> ./build

You should see the words “all done.” at the end of the build process once the binaries are compiled and installed.

Linking WiringPi

When linking a third party library into your C++ project, you usually have to tell the compiler where to find the libraries header and binary files. Thankfully, the build script executed in the compilation process installed these files into our /usr/local/include and /usr/local/lib folders. What is special about these folders is that they are on the system PATH variable, this means that compilers will look for files here by default!

Although we don’t have to tell the compiler where to look, we still have to tell it what to link. Luckily, this is only a one liner with CMake! I have commented each command and highlighted the line which links the wiringPi library. Here is the contents of the complete CMake file (notice I have changed the executable and project name)

# Minimum CMake version required to generate
# our build system
cmake_minimum_required(VERSION 3.0)

# Name of our Project

# add_executable creates an executable with
# The given name.
add_executable(MyEXE main.cpp)

# Make sure the executable links to the wiringPi lib
target_link_libraries(MyEXE wiringPi)

And finally, the code to run to see if the build system will link, compile and run our code:

#include <stdio.h>
#include <wiringPi.h>

int main(int argc, char** argv)

    printf("wiringPi is working!\n");

    return 0;

In the above code, we simply include the wiringPi’s declared functions using the include statement and we are calling the wiringPiSetup function.

To generate the make files, make sure you have a subdirectory called build and make it the working direcotry

> mkdir Build && cd Build

Genreate the makefiles using CMake

> cmake ..

Compile the code

> make

If all goes well, you should be able to execute the program via its executable name and see the line “wiringPi is working!” appear in your terminal.

> ./MyEXE

If you see this, then you are ready to get started with programming in C++ for the Raspberry Pi!

Using WiringPi

Now that we have our program successfully linking and compiling WiringPi, we can now look at preparing the GPIO pins for use in our projects.

If you have come across some of the Python GPIO examples for the Raspberry Pi, the usual procedure is to:

  1. Initialise the GPIO Library
  2. Setup the I/O mode on each GPIO pin you intend to use
  3. Set/Read the pins state dependant on the mode you initiated it as (i.e. input / output)

Luckily, WiringPi is no different! And we’ve already seen from the code above how we initialise the GPIO library.

Just as an example of the functions we will be using in future posts, here is some code (commented on each line) which will set the output & read input from the GPIO pins.

#include <stdio.h>
#include <wiringPi.h>

int main(int argc, char** argv)
    // Intialize the wiringPi Library

    // Set the I/O state of the given pins
    pinMode(0, OUTPUT);
    pinMode(1, INPUT);

    // Turn pin 0 on then off
    digitalWrite(0, HIGH);
    digitalWrite(0, LOW);

    // Read input from pin 1
    int status = digitalRead(1);
    printf("Pin Input = %d\n", status);

    // Exit program
    return 0;

If you copy the above into your main.cpp file from earlier, and recompile the program you should see the line “pin input = 0” when executing. The status will be 0 until there is an input going into the pin… which we will look at when I get to push buttons 🙂

As a quick overall reminder, the full steps to generate your makefiles and compile your code is as follows (don’t execute the contents in brackets):

> cd Build (If not already in Build directory)
> cmake .. (If you have not yet generated makefile / added new files) 
> make     
> ./MyEXE

In the next post I will cover how to setup and make an LED flash using C++. If you want to give this a shot in the meantime though… Use the appropriate GPIO header table for your Pi and setup a GPIO pin in output mode to light up an LED.

Previous Post: Using CMake

Next Post: Our First LED

[ Raspberry Pi C ++] Using CMake

Previous Post: Setting Up The Compiler

Next Post: Compiling and Linking WiringPi for GPIO Access

In a previous post I talked about setting up a compiler on the Raspberry Pi and using g++ on the command line. This is all well and good as a small example with one file, but when you (rightly so) have your code broken up into many files, compiling them via the command line is no longer viable.

To get around this problem, programmers using GCC would create files known as “makefiles”.


Makefiles are GCCs way of passing to the compiler what source files need to be compiled and what they should be compiled into. A downside to using makefiles is that the syntax for them can get extremely cryptic and hard to read/understand when your code base grows.

When you start creating makefiles, you are creating what is known as a “build system” for your project. The more code files you have to manage, the more fundamental your build system becomes.

Different platforms/compilers have different ways of managing build systems for C++ projects. For example, the GCC default is with makefiles whereas Windows uses its own Visual Studio project solution files to manage build types. Technically, there are Windows ports of GCC compilers included in software such as MinGW or Cygwin but this isn’t the norm with regards to Windows programming.

This means that if you want to compile your code on multiple platforms you will have to create and maintain multiple build systems for your project.

For these reasons, programmers tend to look elsewhere for managing their build systems. One such tool is CMake


Note: I just want to make it clear here that CMake does not compile your code! CMake is one level higher than a native build system; infact, it abstracts the underlying build system completely with it’s own syntax and using what it calls “Generators“.

For example, you create your CMake files (described later) as you would your makefiles / Visual Studio files, but you will use a CMake generator to generate your build system files which can range from Makefiles to Visual Studio and Xcode projects. You will then use this generated build system to compile your code. Here is a list of CMake generators readily available.

It’s best to show the process with an example.

CMake Example on Raspberry Pi C ++

Installing CMake

Installing CMake on your Raspberry Pi is made easy by using the apt package manager.

First thing you want to do is SSH into your Pi and at the terminal/command line enter the following

> sudo apt-get install cmake

After a few seconds you should be able to enter the “cmake” command in the terminal and you will see a list of generators available.

Using CMake

For CMake to work, there should be a file named “CMakeLists.txt” in the root directory of your C++ project. In this example, I will have one CMakeLists.txt file and one Hello.cpp file from the previous tutorial.

Your folder structure should look like so:

- Root Folder/
| - CMakeLists.txt
| - Hello.cpp

To create the files enter the following command

> touch <filename.ext>

The contents for each file is as follows (notice each CMake command has a comment describing what it is doing)

#include <stdio.h>

int main(int argc, char** argv)
        printf("Hello, World!\n");
        return 0;

# Minimum CMake version required to generate
# our build system
cmake_minimum_required(VERSION 3.0)

# Name of our Project

# add_executable creates an executable with
# The given name. In our case it is "Hello"
# Source files are given as parameters. In our
# Case we only have one source file Hello.cpp
add_executable(Hello Hello.cpp)

Generating Our Makefiles

Now that we have our CMake file setup with our single source file Hello.cpp, we next need to generate the build system files. CMake will generate quite a lot of files and folders, so it is best not to run the CMake command in the project root directory. Instead we will create a sub folder called “Build” and run the generation in here.

> mkdir Build && cd Build

This will make the directory called “Build” and also change into the directory. This is how your folder structure should look now:

- Root Folder/ 
| - CMakeLists.txt 
| - Hello.cpp
| - Build/

To run the CMake Generator we need to use the “cmake” command and tell it where the root CMakeLists.txt file is. As we are in a sub directory we will use the parent directory alias “..”. If no generator is specified it will default to the platforms native build system (in the Pi’s case, this will be GCC makefiles)

> cmake ..

Once complete you can list the contents of the directory (using the “ls” command) and notice there is now a “MakeFile” present!

Compiling the Code

This bit is easy now that CMake has generated our MakeFile for us!

Simply enter the following into the terminal (make sure you are still in the Build directory)

> make

Provided you copied the code as is above, you should see the line “Built target Hello”. To execute the application enter the following:


You should see the line “Hello, World!”

Previous Post: Setting Up The Compiler

Next Post: Compiling and Linking WiringPi for GPIO Access

[ Raspberry Pi C ++] Setting Up A Compiler (g++)

Previous Post: A Brief Overview of C++

Next Post: Using CMake

In the previous post I talked about how C++ code gets compiled from its source files into an application exe or library. This post will demonstrate setting up a C++ compiler on the Raspberry Pi. More specifically, using g++ which is the C++ compiler in the GNU Compiler Collection (GCC).

Installing G++

The first thing you want to do is log into your Pi via SSH from your main computer. We will install GCC via the apt-get package manager. Open up the terminal and enter the following:

> sudo apt-get install g++

After a few seconds the process will finish, typing “g++” into the terminal should yield the following:

g++: fatal error: no input files
compilation terminated

Testing the Compiler

Now that we have the compiler installed, let’s create a simple C++ program. Using your terminal, create a file called “hello.cpp” with the following command:

> touch hello.cpp

The touch command will create the file if it doesn’t exist, it will also leave the file untouched if it did exist in the first place.

With our file created, let’s enter some simple C++ code. I won’t go over the code here, as it’s only to test the compiler.

Open up the file in your favourite editor (I suggest setting up Visual Studio Code for use with your Pi) and enter the following few lines of code:

#include <stdio.h>

int main(int argc, char** argv)
        printf("Hello, World!\n");
        return 0;
C++ Hello World Example

After saving the file, we must run it through the compiler. You will see in the next tutorial, we will abstract this process using CMAKE, but for the purpose of this tutorial we will pass the file straight to g++ via the terminal/command line.

The g++ CLI requires two parts, the input file(s) to be compiled and the output file these source files will be compiled into. In our case, we have one file to go in and one file to come out (an application executable). The command to do this is:

> g++ hello.cpp -o hello

After a few seconds you should notice another file called “hello” appear in the same directory (those of you using the terminal, you can list all files in the current directory by entering the “ls” command).

This file is the application executable that was compiled from the hello.cpp source file! You can execute it by entering the following:

> ./hello

If you see the words “Hello, World!” appear in your terminal, you can safely say that g++ is set up and ready to go!

Previous Post: A Brief Overview of C++

Next Post: Using CMake

[ Raspberry Pi C ++] The Beginnings, A Very Brief Overview

Next Post: Setting up the compiler

C++ Can be a tough language to pick up, especially if you have no prior programming experience. The usual goto language for beginners with the Raspberry Pi is Python due to its simplicity and enforced structure. Whereas, C++ is the language of choice when speed and efficiency is required but with it, you need to know its quirks.

This post aims to give a brief overview of C++ so that the following tutorials will make sense if you are coming from an inexperienced background with regards to the language and it’s concepts.

If you plan on following the Raspberry Pi C ++ tutorials on this blog, I recommend reading over these posts first:

What is C++?

C++ is a language where the programmer gets full control whereas other languages (such as Python) may abstract certain features. One example is garbage collection, with C++ you have to allocate and deallocate memory for your objects and structures manually. This is obviously an advanced topic to dive into so I will avoid this, but just know that C++ is powerful.

The Compiler

C++ is a compiled language (as opposed to scripting languages such as Python, LUA and C# etc.). What this means is that the code we write has to be passed through a compiler before it can be executed. The compiler will translate the human readable code into instructions that the computer will understand – this is targeted at the CPU architecture. For example, the Pi has an ARM CPU, this means that the C++ compiler has to translate the human readable code into ARM instructions.

There are quite a lot of compilers out there, but our focus will be using the G++ compiler (the C++ subset of the GCC compilation set) for use with the Raspberry Pi.

The Structure

With C++, it is vital to break your code up into multiple files. The two main file types you will come across is a .h file and a .cpp file.

The .h file (AKA a “Header File”) is used to declare your classes / function “prototypes”. Whereas a .cpp (AKA a “Source File”) is where you define these functions / classes. The difference being that a declaration is like saying “Hey, there is a function in my code called MyFunction” and a definition is “Hey, this is what MyFunction is going to do when called”.

To put this into an example, here are two snippets of code:

// declaration of function "HelloWorld"
void HelloWorld();

#include "Hello.h"

// definition of function "HelloWorld"
void HelloWorld()
    printf("Hello, World!");

You may note the line “#include “Hello.h””. This is called an “include statement”, and is how a source file knows where to look for function declarations. When using a third party library, this is how you include their function declarations into your code.

Compilation Types

Now that we know of a compiler and what file types are being used, we finally need to know what to compile our code into. There are 3 main compilation types:

  • Application executable (.exe on Windows, Linux doesn’t really have a set file extension for these)
  • Static Library (.lib on Windows, .a on Linux)
  • Shared Library (.dll on Windows, .so on Linux)

An application executable is as it sounds, an application that you can execute either from double clicking it’s file icon or from the terminal. Code compiled into an executable cannot be used directly in other projects.

The two library types (static and shared) are used for code that could potentially be shared across multiple projects. There is a difference between the two types but it is out of scope for this brief overview. Just know that any third party libraries you come across will more than likely be compiled into one of these forms.

The term for using a library in your C++ application is called ‘linking’. To link a library into your code, you must pass the library name along with the location of where the compiler will find its .a or .so file.

Further Reading

I obviously cannot cover how to program in C++, this is way overkill for these tutorial posts but is covered extensively online / in books. I just want to give an overview on how a compiler can take C++ code and compile it into an application / library files. Maybe one day I will make a post going into detail on each step which would be fun!

Next Post: Setting up the compiler

Understanding SSH Keys

What Are SSH Keys?

As opposed to the usual username and password authentication method, you can establish an SSH connection using a method that is known as SSH key-based authentication.

SSH keys are considered an extremely secure way of logging into your device/server, and is often the recommended way to establish all SSH connections as opposed to username and password authentication.

SSH keys come in pairs (private & public). The private key remains a secret to the client (i.e. the computer you use to initiate an SSH connection). This private key is considered the most vital, as any access to a private key can compromise your device and allow attackers to log in over SSH.

As opposed to your private key, your public key can be shared freely as only your private key can decrypt messages sent over SSH using said public key. This public key is uploaded to the device you wish to access via SSH and is stored in a specific file within the home directory of the user you wish to log in as.

How a Secure Connection is Formed

When we attempt to log into our device over SSH, using key-based authentication, the remote device will respond with a message which the SSH client (our computer/laptop we are using to initiate an SSH connection) must encrypt using its locally stored private key.

The client then responds with this encrypted message, which the remote device will then attempt to decrypt using one of the public keys originally uploaded in the setup procedure.

If the remote device successfully decrypts the message (I.e., if the original message matches the decrypted message), then an SSH connection is authenticated.

Understanding this connection method really shows how vital it is to safely secure your private SSH key.

Creating a Private & Public Key

It is worth noting at this point, that the command to generate a private & public key-pair exists on Linux/Mac computers by default (or at least after installing the OpenSSH libraries). Windows users will need to download a program such as Git and expose it’s commands on the system path.

The command to generate a key-pair is

> ssh-keygen

Upon entering this in the command prompt/terminal (on the local client), you will be asked to enter a location to save the keys. By default, this command creates two files, id_rsa and in the .ssh folder found in the home directory of the currently logged in user. For example:



You can simply click enter at this point, to save in the default location (recommended).

If you wish to encrypt the keys on disk (recommended) you can do so now. If you do not wish to enter a passphrase, simply leave it blank and hit enter.

Uploading Your Public Key to Remote Device

Now that we have our private and public key-pair stored on our client, we are ready to upload our public key to the special file which stores all accepted public keys on the remote device. It is important to note, that the location is stored in the .ssh folder in the home directory of the user.

For example, if we want to log in as the user “bob” but we upload our public key to the user “brian” then we won’t be able to initiate an ssh connection via bob@<remoteIP>, but we would be able to via brian@<remoteIP> .

So, first things first is to get the contents of your public key (on the local client). This can be done by cat’ing your public key to the terminal via:

> cat ~/.ssh/

You will see a massively long string (key based authentication is very secure!). You simply need to copy all of this output.

Now on your remote device, log into the account of the user you wish to log in via SSH as and append your public key by entering the following in the command prompt:

> echo your_public_key >> ~/.ssh/authorized_keys

Where “your_public_key” is the contents of the file you originally copied.

NOTE: You may have to ensure your SSH directory exists if you have not set this up before. You can do this simply by entering the following (safe to do, if the directory already exists)

> mkdir –p ~/.ssh

Log in via Key-based SSH

With your public key uploaded to the remote device, we can now go back to our local client. We can attempt to initiate an ssh key-based connection by entering the following

> ssh username@<remoteIP>

If you entered a passphrase for your private key file, you will be prompted to enter that passphrase now. Otherwise your connection will be established.

If you wish to disable password authentication (I.e. a less secure authentication method), you can do so by entering the following on the remote device

> sudo nano /etc/ssh/sshd_config

Ensure the following line exists and not commented out (via a # symbol)

PasswordAuthentication no

Finally press ctrl + X to exit the file and “Y” to confirm changes.

You will then need to restart the machine.

Execute Script on Startup [Raspberry Pi]


Getting your script to execute when you boot up your Raspberry Pi can be very useful. For example, connecting your Raspberry pi to your Synergy server automatically when it turns on so you don’t need to plug in a keyboard just to execute the “startsynergy” command.

We will focus our setup around the Raspbian OS. Even though the setup is different between the Raspbian GUI OS and the Headless OS (Raspbian Lite), the processes is still fairly straight forward. This guide will demonstrate how to do it on both Operating Systems.

Raspbian Lite (Headless OS)

I will start off with the easiest of the lot. As you boot up into a terminal in an headless environment, we can use the .bashrc file of the user you are logging in as.

First ensure that the file exists (it should by default… but just encase…)

> sudo touch ~/.bashrc

This will create (if not already created) a .bashrc file within the currently logged in users home directory. Next we want to edit this file using the Nano Text Editor:

> sudo nano ~/.bashrc

With our .bashrc file open, scroll all the way to the bottom of the file using your keyboards arrow keys. On the last line of the file (but before any exit statements) type the script you want to execute in the exact same way as you would in the terminal. For example, if I wanted to execute a python script, I enter the following

python ~/Scripts/

Notice how I am using an absolute path to the file (~/ is a shortcut to the home directory of the logged in user). It is best to stick to absolute paths for this kind of stuff.

When you’re done, press “CTRL + X” to exit and “Y” to confirm changes. Reboot your Pi and you should see your script execute!

Caveat: One thing to note is, this script will run every time you open up a terminal. So if you log into your Pi via SSH from your main PC, this script will run again. If you have a long running script, you can press “CTRL + C” to break out of it early.

Raspbian GUI

Executing a script on startup with the Raspbian GUI is slightly different. The script has to be executed when the desktop environment loads. We can edit the file which runs when this event occurs by opening it with Nano:

> sudo nano /etc/xdg/lxsession/LXDE/autostart

Like our .bashrc file, we must add our script to the end of this file (but again ensuring we put it before any exit statements). For this example, I will use our startsynergy script we created some posts ago. It is launched via bash, so the line would look as follows:

@/usr/bin/bash ~/startsynergy

Upon restarting the Pi, and providing you have your Synergy Server running, your Pi should now auto connect to your Synergy Server without the need for manual intervention.

Likewise, if you want to execute python scripts, for example, you can do so in the following manner:

@/usr/bin/python /path/to/my/python/

To save the file hit “CTRL + X” and “Y” to confirm changes. Upon rebooting your Pi and logging into the desktop, you should notice that your script executes.