Advertisements

Booting Raspberry Pi2 for the first time

Today I and my colleagues were trying to install Raspbian OS on Raspberry Pi 2 B version. The steps that we followed are explained below.
Before explaining the steps, I am listing down the hardware and softwares that we used.

  • Raspberry Pi2 B version
  • NOOBS 1.4.1 Offline and Network Installer (Release date 2015-05-11).
  • Transcent 16 GB Class 10 memory card
  • Raspberry Pi charger (We used a 5Volt 2A charger)
  • Memory Card Reader.
  • SD Formatter (https://www.sdcard.org/downloads/formatter_4/)
  • Windows Laptop
  • Monitor
  • HDMI Cable

We used the steps mentioned in the raspberry pi website for reference. There is an excellent video that explains each and every step for the setup.

pi21GB
The steps we followed are listed below.

  • Inserted the memory card into the Card reader and plugged into the windows machine.
  • Formatted the memory card using the SD Formatter with “FORMAT SIZE ADJUSTMENT” set to “ON”.
  • Copied the NOOBS offline installer zip file to the formatted memory card and extracted it.
  • Unplugged the card reader and put the memory card into the Pi2.
  • Supplied power to the Pi2 which is connected to the monitor using HDMI Cable
  • The Pi2 booted up. We have to select the OS to be installed.
  • Select one OS. Now the OS will be installed and your pi will be ready to use.

Note:
We faced an issue while performing the installation. The Pi2 was not booting up. Finally after some struggle, we figured out the issue. We used a phone instead of a memory card reader for connecting the memory card to the computer for formatting. Because of this, the Pi was not booting. We figured out this issue from the status of the ACT LED (Green LED). The green LED should blink in case of normal operation. If the green LED is not blinking, means the Pi is not reading the SD card. In our case the green LED was not blinking. So we started investigating and reviewing the steps that we followed for the SD card set up and finally we found the culprit… Our Mobile Phone . So my suggestion is to use a card reader. Never use any camera or mobile phone instead of card reader. This may unnecessarily waste your time and you will not get any clue of the error also.

Advertisements

SSH Key based access to Unix Servers

Access to Linux and Unix systems via Secure Shell (SSH) is standard practice.  It offers encrypted access to enable you to administer your server which is vital over the big bad internet.

There are different ways to access SSH: password, user keys and host-based keys.  Passwords are the most common but are less secure than key-based access.  Passwords are susceptible to keylogger attacks, as well as more likely to fool users into a “man-in-the-middle” attack (one where you think you’re logging onto your server, but you are actually proxying your connection through another server which has been compromised and is recording every keystroke and data transfer.)

Key based access is more secure as it requires two parts of a key to be present before access is granted.  When dealing with cloud based services such as Rackspace and Amazon Web Services, key based access is enabled by default.  Key based access is also known as “passwordless access” as access is granted by your key, not by asking for any passwords.  The exception to this is if you put a password on your key (but you can enable services that ask for this password once and it is cached for the rest of your session).

Setting this up on your Linux server is very simple, and most installations of SSH (OpenSSH) enable both password and key-based access by default.  Let’s assume user@client needs to access user@server

Ensure OpenSSH is installed on your Linux server (server)

Debian/Ubuntu

sudo apt-get install openssh-server

CentOS/Fedora/RedHat/Oracle Enterprise Linux

sudo yum install openssh-server

Ensure the following lines has been uncommented from /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes

Restart OpenSSH

Debian/Ubuntu

sudo /etc/init.d/ssh restart

CentOS/Fedora/RedHat/Oracle Enterprise Linux

sudo /etc/init.d/sshd restart

On your Linux client (desktop or other server you’ll be using to connect to the server configured in steps 1-3)

Generate your public and private keys

ssh-keygen -t rsa

You will see output like the following:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory ‘/home/user/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
79:e1:08:77:c2:0d:c4:ff:35:22:64:9a:4d:03:b8:67 user@client
The key’s randomart image is:
+–[ RSA 2048]—-+
|       ++.                      |
|      …o=                    |
|      ..+O+.                 |
|      .oE*+.. o             |
|       oS oo o .            |
|         .  .                     |
|                                  |
|                                  |
|                                  |
+—————–+

This produces two important pieces of data.  Your PRIVATE KEY (~/.ssh/id_rsa) and your PUBLIC KEY (~/.ssh/id_rsa.pub).  You must keep your PRIVATE KEY safe.  Your public key can be given to anyone.  Without your private key your public key is just a string of characters and you can’t generate a private key from a public key.  Equally, you can’t generate a public key from a private key.  Together they make your key-pair.
To enable your private key to access the server running SSH configured in steps 1-3 (server) you simply copy the contents of your public key onto the server.
Copy the public key from your client machine to server

scp .ssh/id_rsa.pub user@server:
(enter your password)

Login to server

ssh user@server
(enter your password)

Copy the public key to authorized_keys

cat .ssh/id_rsa.pub >> .ssh/authorized_keys

Change the permission of authorized_keys file to 600 (rw——-)

chmod 0600 .ssh/authorized_keys

This creates the directory .ssh/ and relevant authorized_keys file with the correct permissions (anything less strict will not work).  You can put in a number of public keys in here, line-by-line.  When there are multiple entries it allows multiple people to connect to that account using their keys.  This becomes useful when a team of system administrators require access to systems with minimal accounts installed, but each are accountable for audit purposes as to who logged onto the system.

Log out of that session and log back in again and you shouldn’t be asked for a password.