public/private key generation

This short tutorial will show you how to generate some keys which you can use with openssl/ssh to gain access to machines.

Basically you will create a very strong (by today’s standards) mathematically bound pair of keys which when used in combination ensure trusted communication between two parties.

Which two parties? Your local machine, and a server that you already have access to. The pair of keys you will generate have one that is public (you can freely distribute this, and in fact you will at least place this on the server you want to access). The other is private and the real foundation of the secure communication. Your web traffic will only be as strong as this private key. That is to say, if the location or machine you store your private key on is not secure, then the places you access will not be secure.

For ease of use you may choose not to encrypt the use of your private key with a passphrase. This makes connecting using the key a simple matter, and very handy for automatic connections (no more remembering passwords!). The disadvantage here is that if your key is compromised (someone else gets it), they will be able to go anywhere you could have with it. Even with the addition of a simple passphrase, you can increase the security of the private key. The disadvantage is that you’ll have to enter a passphrase every time you use the key. Your call.

To generate the key:

$ ssh-keygen -t rsa -b 4096

This says you want an RSA key of 4096 bit length. (This is very robust, as of Spring 2015).
You will be asked for a name (it defaults to id_rsa and id_rsa.pub). You generate multiple keys and manage them as you wish. I’ve found it useful to use my last name, this makes putting the public key part on a shared server less confusing for team development, when others will be doing the same thing with their keys.

You will want to immediately change the permissions on your private key so that you will be the only one to be able to read it.

$ chmod 400 nameOfYourPrivateKey_id_rsa

Only someone logged in as you will be able to read (copy) this key now. On machines like OS X, anyone with an administrator account (or root) will also be able to access it. Basically, your key is only as secure as the physical well being of your laptop. If you suspect that your key is compromised let a team member know and the public key on the server can be removed so that particular key pair won’t work anymore.

Work with a team member to get the public key onto the server. It needs to go into a specific place depending on what resource you want to access.


This is how you use the key:

$ ssh -i pathToKey user@machine.domain.tld

If the key pair matches up you’ll be logged in and good to go.
To make this even more handy, you can write an alias:

alias comdevRoot=’ssh -i ~/.ssh/lasota_id_rsa root@communitydev.uaf.edu’

Put that in your .bash_profile and then everytime you enter ‘comdevRoot’, you’ll gain shell access to communitydev.

You can also copy files using scp (secure copy).

$ scp -i path_to_SourceFile path_to_Destination_File_or_Directory

The path should be a full path when you are specifying the location of a file on the foreign machine (server you are working with). Also, the foreign machine needs the user under which you will be placing or retrieving files from. Ex:

$ scp -i ~/.ssh/lasota_id_rsa myWebPage.html root@communitydev.uaf.edu:/var/www/public_html/

The above places a web file into the /var/www/public_html directory. It will be owned by root on the web server.

You can also use wildcards to copy over all the files:

$ scp -i ~/.ssh/lasota_id_rsa * root@communitydev.uaf.edu:/var/www/public_html/project/

This would copy over all of the visible files in the current directory and put them into the project directory on the server. Note that files are overwritten on the foreign server.

Good Luck Jim.

Students Construct


This is completely Optional!

Some of you have access to the T3alliance.org Raspberry Pi Computer Boxes with the included sensor devices, breadboard and other parts. If you do, you can follow along and recreate and improve some of these projects. These are optional. At this point in the course, we have not covered some of the programming concepts involved here. If you copy and paste the program into Thonny and save it, you’ll be able to run it, and control your RPi pins and associated breadboard LEDs if you have those.

The good news is that by the end of the course, you will understand all of the program which I have provided, and I am sure you will discover new ways to control external devices. For now, just consider this a fancy “Hello World” program that instead of printing out a message, lights up some LEDs.


Additional Learning Objectives

  1. Use a breadboard to create temporary circuits
  2. Use external devices to communicate the state of a program
  3. Direct power from specific pin outs on the RPi I/O board

Above is the program in action. I ran the program four times and selected a different pin each time.

The Program

import RPi.GPIO as GPIO
GPIO.setup(4, GPIO.OUT, initial=GPIO.LOW)
GPIO.setup(13, GPIO.OUT, initial=GPIO.LOW)
GPIO.setup(17, GPIO.OUT, initial=GPIO.LOW)
GPIO.setup(18, GPIO.OUT, initial=GPIO.LOW)

answer=input("Which LED do you want to light up? (Enter: 4, 13, 17 or 18) ")

Program comments:

  • The program uses the RPi.GPIO library with pre-built commands which add to Python’s abilities
  • The program starts by letting the RPi know which pins I will be using and automatically turns each to GPIO.LOW which is the same as “OFF”
  • The program uses the Input ( ) command to ask the user a number. (This is how it switches the LEDs off/on).
  • The program will try to turn the light on, and then quit. If you want to light a different light, just run the program again and provide a different number.


In the picture below, the pins from Raspberry Pi are shown. Each is labeled. This program uses 5 pins:

  1. #4 wire to Green LED landing at hole 4e
  2. #13 wire to Yellow LED landing at hole 13e
  3. #17 wire to Blue LED landing at hole 17e
  4. #18 wire to Red LED landing at hole 18e
  5. GND (ground, any pin marked ground will work, but I used the lower left pin)



In the picture below is my breadboard near the Raspberry Pi. I used the same color wire as the LED which was being powered. Note that the positive side of the LEDs is longer than the negative side (shorter). All the LEDs have their positive wire placed in the “a” column, and their negative pins (the shorter one), placed in the Blue rail line.

Notice how the resistor connects the Blue rail line with the Red Rail line. Additionally, there is one last wire connecting the Red rail line with the GND pin back on the RPi.


Below is a schematic diagram showing the pin connections on the breadboard. Note that the LEDs have direction. LEDs only allow electricity to flow one way through them (from the longer positive wire, through the bulb, and out the negative shorter wire). Resistors don’t have polarity, current can flow in either direction.

schematic diagram for breadboard and LED circuit


This should be all you need to get this program running, especially if you have experience with the RPi input/output pins.

Questions / Victories

If you’d like to ask a question about this, or would like to share a picture of your working project, please use this discussion thread for RPi GPIO project Part 1.