Home‎ > ‎Dabbles‎ > ‎

RaspberryPi

RaspberryPi 230 - Implementing a VPN Server

posted Dec 4, 2015, 3:28 PM by Joshua S

This tutorial will demonstrate how to build a Virtual Private Network (VPN) server.  This will allow remote devices (PCs, Phones, Tablets, etc.) to connect to your network via the RaspberryPi from anywhere on the Internet.  Through this connection, you will be able to use that device as if it were connected locally on your network.  You may use this so you can access your printer, other computers, or storage devices, or so you can access an unfiltered internet if you are at work or somewhere else that filters your connection.
  • Note -- this tutorial uses PKI via a separate Certificate Authority (CA), but there was an early Dabble I created that deploys an all in one solution here
  • Note -- this tutorial uses exclusively PKI authentication -- there is a way to tie in OpenLDAP as a part of this process, but that will be saved for a possible future Dabble.
This project assumes you have a static IP set for the RaspberryPi.  No instructions speak to this, because they will vary based upon your environment and where you implemented DHCP.  Generally speaking, this is something you will configure at your router by supplying the MAC address of the Pi.  Additionally, the router will need to be configured to port forward TCP port 1194 (or whatever port you choose to implement for the VPN) to the RaspberryPi.  Note, OpenVPN is often configured to use UDP, but this protocol is also often blocked thus TCP will work much more consistently and is what I show in this Dabble.

With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

Supply List:
  • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
  • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
Prerequisites:

Project:
  • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
    • Buying a MicroSD Card
    • Buying a RaspberryPi 
    • Finding the IP Address of your Pi
      • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
    • Obtaining and installing PuTTY
https://xkcd.com/1343/
  • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
  • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
  • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
  • UserID:  pi 
  • Password:  raspberry

  • OK, good!  Now that we are connected, let's install let's install OpenVPN:
sudo apt-get -y install openvpn
    • openvpn  virtual private network daemon.

  • We need to start by creating a directory for our keys:
sudo mkdir /etc/openvpn/keys
sudo chmod 400 /etc/openvpn/keys

  • We need to then import the following files into our key folder -- these should be generated through your Certificate Authority and then moved to your VPN server:
    • CA Certificate (ca.crt.pem)
    • Server Certificate (vpnserver.crt.pem)
    • Server Key (vpnserver.key.pem)
    • Diffie-Hellman Parameters (dh4096.pem)
  • Let's create our server TLS certificate using the following command:
sudo openvpn --genkey --secret /etc/openvpn/keys/ta.key

  • With the files in place, let's configure our server using the /etc/openvpn/server.conf file.  This will tell OpenVPN how we want it to operate.  I've attached a copy of the file used in this dabble at the end of this lesson for reference.  Make sure to update the following fields:
sudo nano /etc/openvpn/server.conf

local <the Pi's IP Address>
dev tun
proto tcp
port 1194
ca /etc/openvpn/keys/<the CA certificate>
cert /etc/openvpn/keys/<the VPN Server certificate>
key /etc/openvpn/keys/<the VPN Server key>
dh /etc/openvpn/keys/<the Diffie-Hellman Parameters>
server 10.8.0.0 255.255.255.0
# server and remote endpoints
ifconfig 10.8.0.1 10.8.0.2
# Add route to Client routing table for the OpenVPN Server
push "route 10.8.0.1 255.255.255.0" 
# Add route to the Client routing table for the OpenVPN Subnet
push "route 10.8.0.0 255.255.255.0"
# Your local subnet
push "route 192.168.0.0 255.255.255.0"
# Set primary domain name server access to the SOHO Router
# If your router does not do DNS, you can use Google DNS 8.8.8.8
push "dhcp-option DNS <DNS Server IP Address>"
push "dhcp-option DOMAIN <your domain>"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0.  This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway defl"
client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/keys/ta.key 0
cipher AES-256-CBC
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 1

  • With the server configuration complete, we need to update the system control configuration to ensure traffic coming into the VPN is forwarded onto the local network.  To do this, let's edit the /etc/sysctl.conf file using nano.  I've attached a copy of the file used in this dabble at the end of this lesson for reference.  Make sure to update the following field:
sudo nano /etc/sysctl.conf

net.ipv4.ip_forward=1

  • With these changes configured, we need to apply them using the following command:
sudo sysctl -p

  • OK, OpenVPN is now configured, but we need to update the RaspberryPi's firewall rules to allow traffic to be routed through the Pi.  It's best to use a script to accomplish this and locate it at /etc/firewall-openvpn-rules.sh.  First, create the script by issuing the nano command to edit the file (it is implicitly created) then insert the following lines.  I've attached a copy of the script at the end of this lesson for reference.  
sudo nano /etc/firewall-openvpn-rules.sh

#!/bin/sh

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --tosource <VPN Server Address>


    • With the script created, we need to update the file permissions to ensure it is well protected.  Do that by executing the following commands to update the access control list and owner of the file.
    sudo chmod 700 /etc/firewall-openvpn-rules.sh
    sudo chown root /etc/firewall-openvpn-rules.sh

    • Good, now that we have the script created, we need to have it execute each time the network interface loads.  We do this by editing the /etc/network/interfaces file using nano.  I've attached a copy of the script at the end of this lesson for reference.  Edit the file using the following command and add the following line beneath the iface for eth0:
    sudo nano /etc/network/interfaces

    pre-up /etc/firewall-openvpn-rules.sh

    • Congratulations!  Your VPN is now ready to go!  You should reboot your Pi, validate your port forwarding, and then try to connect by using the external IP address of your router!

    RaspberryPi 223 - Signing Client Certificates

    posted Nov 29, 2015, 6:06 AM by Joshua S   [ updated Nov 29, 2015, 2:31 PM ]

    This tutorial will sign a Client Certificate using an Intermediate Certificate Authority (CA) created by the RaspberryPi's builtin OpenSSL framework.  Client certificates are used to support authentication and authorization to a number of clients where as client certificates are used primarily for user authentication.  

    To give credit where credit is due; this lesson is based heavily off of this lesson from others.  For a really good overview of the concepts behind CAs and PKI, check out this post.

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry
    • First things first, in the previous dabble, we created the directories for the intermediate Certificate Authority (CA).  Now, we need to create a server key.  
      • Note -- this is written from the perspective of a Certificate Authority.  Third parties can also issue their own certificate signing requests (CSR) using their own private keys for us to sign and issue a certificate, but that is a different process for a different dabble.  
      • Note -- while the CAs used 4096 bit keys, most server and client certificates use no larger than 2048 bit (many use 1024 bit) keys in the interest of balancing security with the performance of the TLS "handshake".  As a result, this dabble will use 2048 bit keys for the server and client certificates.
      • Note -- certificates can be issued with or without passwords.  Passwords do make the certificate much more secure, but they also introduce the need to enter the password before use.  As a result, often server certificates do not use passwords (you would need to re-enter the password each time you restart a webserver, for example), some client certificates focused on services such as LDAPS or authentication of an embedded device also do not use passwords, but passwords should be used for client certificates needed for authentication in services such as VPN to ensure the authorized user is presenting the certificate.  Inclusion of the -aes256 option determines if a password will be tied to the certificate.
    sudo openssl genrsa -aes256 -out /root/ca/intermediate/VPN/private/vpn.client.key.pem 2048
    <Client Password>
    sudo chmod 400 /root/ca/intermediate/VPN/private/vpn.client.key.pem

    • With the key created, we need to generate a Certificate Signing Request (CSR) in order to create the actual certificate.  
      • Note -- based on the configuration we used earlier to create the intermediate CA, the CSR details don’t need to match the intermediate CA, but I like to keep everything matching as a best practice. 
      • Note -- for server certificates, the Common Name must be a fully qualified domain name (FQDN) such as vpn.academicdabbling.com, whereas for client certificates it can be any unique identifier such as a device name or eMail address. 
      • Note -- the Common Name can not be the same as either your root or intermediate certificate.
    sudo openssl req -config /root/ca/intermediate/VPN/openssl.cnf -key /root/ca/intermediate/VPN/private/vpn.client.key.pem -new -sha256 -out /root/ca/intermediate/VPN/csr/vpn.client.csr.pem
    <Client Password>
    <Your CA / Organizational details>


    • Now, to convert our CSR to a certificate, we will use the intermediate CA to sign the CSR.  Since, the certificate is going to be used on a client, we will use the usr_cert extension. 
      • Note -- if the certificate were to be used for a server, we would use the server_cert extension instead. 
      • Note -- certificates are usually given a validity of one year.  This way, though they are publicly facing and at greater risk of compromise, the risk is limited to a one year period.  Consider -- the one year expiration requires the certificate to be reissued at the end of that period; thus may projects or small businesses will issue for a greater period of time despite the risk.
    sudo openssl ca -config /root/ca/intermediate/VPN/openssl.cnf -extensions usr_cert -days 365 -notext -md sha256 -in /root/ca/intermediate/VPN/csr/vpn.client.csr.pem -out /root/ca/intermediate/VPN/certs/vpn.client.cert.pem
    <Intermediate CA Password>
    y
    y
    sudo chmod 444 /root/ca/intermediate/VPN/certs/vpn.client.cert.pem

    • Let's make sure the root CA registered the signature process.  To do this, we need to look in the index.txt file of the root CA using the cat command.  Review any entries to ensure our new intermediate CA is listed.
    sudo cat /root/ca/intermediate/VPN/index.txt

    • Good -- we know the certificate was signed, now let's check that the details of the cert look correct using OpenSSL.  Validate the details to ensure they align with your inputs.  In particular, the Issuer should be the intermediate CA and the Subject should refer to the certificate itself.
    sudo openssl x509 -noout -text -in /root/ca/intermediate/VPN/certs/vpn.client.cert.pem

    • OK -- now that we know the details look good, let's validate the intermediate CA cert against the root cert to ensure the chain of trust is intact.  If we get a response of "OK" we know everything worked.
    sudo openssl verify -CAfile /root/ca/intermediate/VPN/certs/ca-chain.cert.pem /root/ca/intermediate/VPN/certs/vpn.client.cert.pem

      • If you are using this certificate with an application that requires Diffie-Hellman parameters, you need to add those to the certificate now.  This is optional as many services and applications do not require this.  You should have created a Diffie-Hellman parameter file when you created your intermediate Certificate Authority and it should follow the naming convention "dh<key size>.pem" (ex. dh2048.pem).  Issue the following command to add these parameters to your certificate.  Note, these commands were performed as root.
      sudo su root
      chmod 644 /root/ca/intermediate/VPN/certs/vpn.client.cert.pem
      cat /root/ca/intermediate/VPN/certs/dh2048.pem >> /root/ca/intermediate/VPN/certs/vpn.client.cert.pem
      chmod 444 /root/ca/intermediate/VPN/certs/vpn.client.cert.pem


      • OK, good.  Let's check our work -- if everything worked as planned, we'll see the Diffie-Hellman parameters appended to the bottom of the certificate.
      sudo cat /root/ca/intermediate/VPN/certs/vpn.client.cert.pem


    • You can now deploy the certificate to the client -- this process is unique to each client and application, but perhaps there will be future dabbles about this.  Ensure the following files are available to the client:
      • vpn.client.key.pem
      • vpn.client.cert.pem
    • Congratulations!  Your server certificate is now issued and ready to go!  

    RaspberryPi 222 - Signing Server Certificates

    posted Nov 28, 2015, 1:10 PM by Joshua S   [ updated Nov 29, 2015, 2:33 PM ]

    This tutorial will sign a Server Certificate using an Intermediate Certificate Authority (CA) created by the RaspberryPi's builtin OpenSSL framework.  Server certificates are used to support authentication and authorization to a number of clients where as client certificates are used primarily for user authentication.  

    To give credit where credit is due; this lesson is based heavily off of this lesson from others.  For a really good overview of the concepts behind CAs and PKI, check out this post.

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry
    • First things first, in the previous dabble, we created the directories for the intermediate Certificate Authority (CA).  Now, we need to create a server key.  
      • Note -- this is written from the perspective of a Certificate Authority.  Third parties can also issue their own certificate signing requests (CSR) using their own private keys for us to sign and issue a certificate, but that is a different process for a different dabble.  
      • Note -- while the CAs used 4096 bit keys, most server and client certificates use no larger than 2048 bit (many use 1024 bit) keys in the interest of balancing security with the performance of the TLS "handshake".  As a result, this dabble will use 2048 bit keys for the server and client certificates.
      • Note -- certificates can be issued with or without passwords.  Passwords do make the certificate much more secure, but they also introduce the need to enter the password before use.  As a result, often server certificates do not use passwords (you would need to re-enter the password each time you restart a webserver, for example), some client certificates focused on services such as LDAPS or authentication of an embedded device also do not use passwords, but passwords should be used for client certificates needed for authentication in services such as VPN to ensure the authorized user is presenting the certificate.  Inclusion of the -aes256 option determines if a password will be tied to the certificate.
    sudo openssl genrsa -out /root/ca/intermediate/VPN/private/vpn.academicdabbling.com.key.pem 2048
    sudo chmod 400 /root/ca/intermediate/VPN/private/vpn.academicdabbling.com.key.pem

    • With the key created, we need to generate a Certificate Signing Request (CSR) in order to create the actual certificate.  
      • Note -- based on the configuration we used earlier to create the intermediate CA, the CSR details don’t need to match the intermediate CA, but I like to keep everything matching as a best practice. 
      • Note -- for server certificates, the Common Name must be a fully qualified domain name (FQDN) such as vpn.academicdabbling.com, whereas for client certificates it can be any unique identifier such as a device name or eMail address. 
      • Note -- the Common Name can not be the same as either your root or intermediate certificate.
    sudo openssl req -config /root/ca/intermediate/VPN/openssl.cnf -key /root/ca/intermediate/VPN/private/vpn.academicdabbling.com.key.pem -new -sha256 -out /root/ca/intermediate/VPN/csr/vpn.academicdabbling.com.csr.pem
    <Your CA / Organizational details>

    • Now, to convert our CSR to a certificate, we will use the intermediate CA to sign the CSR.  Since, the certificate is going to be used on a server, we will use the server_cert extension. 
      • Note -- if the certificate were to be used for user authentication, we would use the usr_cert extension instead. 
      • Note -- certificates are usually given a validity of one year.  This way, though they are publicly facing and at greater risk of compromise, the risk is limited to a one year period.  Consider -- the one year expiration requires the certificate to be reissued at the end of that period; thus may projects or small businesses will issue for a greater period of time despite the risk.
    sudo openssl ca -config /root/ca/intermediate/VPN/openssl.cnf -extensions server_cert -days 365 -notext -md sha256 -in /root/ca/intermediate/VPN/csr/vpn.academicdabbling.com.csr.pem -out /root/ca/intermediate/VPN/certs/vpn.academicdabbling.com.cert.pem
    <Intermediate CA Password>
    y
    y
    sudo chmod 444 /root/ca/intermediate/VPN/certs/vpn.academicdabbling.com.cert.pem

    • Let's make sure the root CA registered the signature process.  To do this, we need to look in the index.txt file of the root CA using the cat command.  Review any entries to ensure our new intermediate CA is listed.
    sudo cat /root/ca/intermediate/VPN/index.txt

    • Good -- we know the certificate was signed, now let's check that the details of the cert look correct using OpenSSL.  Validate the details to ensure they align with your inputs.  In particular, the Issuer should be the intermediate CA and the Subject should refer to the certificate itself.
    sudo openssl x509 -noout -text -in /root/ca/intermediate/VPN/certs/vpn.academicdabbling.com.cert.pem

    • OK -- now that we know the details look good, let's validate the intermediate CA cert against the root cert to ensure the chain of trust is intact.  If we get a response of "OK" we know everything worked.
    sudo openssl verify -CAfile /root/ca/intermediate/VPN/certs/ca-chain.cert.pem /root/ca/intermediate/VPN/certs/vpn.academicdabbling.com.cert.pem

    • If you are using this certificate with an application that requires Diffie-Hellman parameters, you need to add those to the certificate now.  This is optional as many services and applications do not require this.  You should have created a Diffie-Hellman parameter file when you created your intermediate Certificate Authority and it should follow the naming convention "dh<key size>.pem" (ex. dh2048.pem).  Issue the following command to add these parameters to your certificate.  Note, these commands were performed as root.
    sudo su root
    chmod 644 /root/ca/intermediate/VPN/certs/vpn.academicdabbling.com.cert.pem
    cat /root/ca/intermediate/VPN/certs/dh2048.pem >> /root/ca/intermediate/VPN/certs/vpn.academicdabbling.com.cert.pem
    chmod 444 /root/ca/intermediate/VPN/certs/vpn.academicdabbling.com.cert.pem

    • OK, good.  Let's check our work -- if everything worked as planned, we'll see the Diffie-Hellman parameters appended to the bottom of the certificate.
    sudo cat /root/ca/intermediate/VPN/certs/vpn.academicdabbling.com.cert.pem


    • You can now deploy the certificate to a server -- this process is unique to each server and application, but perhaps there will be future dabbles about this.  Ensure the following files are available to the server:
      • ca-chain.cert.pem
      • vpn.academicdabbling.com.key.pem
      • vpn.academicdabbling.com.cert.pem
    • Congratulations!  Your server certificate is now issued and ready to go!  

    RaspberryPi 221 - Implementing an Intermediate Certificate Authority

    posted Nov 22, 2015, 2:59 AM by Joshua S   [ updated Nov 30, 2015, 3:00 AM ]

    This tutorial will implement an Intermediate Certificate Authority (CA) using the RaspberryPi's builtin OpenSSL framework.  This allows us to create sub-CA's under the authority of the primary CA.  You can do this for many reasons -- perhaps one is for VPN while another is for LDAPS, but more importantly, this allows you to revoke a certificate -- or an entire root certificate -- in the event of compromise while still maintaining the broader web of trust and making restoration of operations much simpler.

    To give credit where credit is due; this lesson is based heavily off of this lesson from others.  For a really good overview of the concepts behind CAs and PKI, check out this post.

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry
    • First things first, in the previous dabble, we created the directories for the primary Certificate Authority (CA).  Now, we need to set up the directory structure, called intermediate, to support Intermediate Certificate Authorities.  Note -- if you have set up an Intermediate Certificate Authority previously using these Dabbles then skip on to the next step and do not attempt to recreate this directory.
    sudo mkdir /root/ca/intermediate

    • With the main directory structure for the intermediate CAs created, it is time to create the the intermediate CA that we specifically want to deploy.  In this example, let's call it VPN as we'll plan to use these certificate pairs to deploy a VPN in a later lesson.
    sudo mkdir /root/ca/intermediate/VPN

    • we need to create a directory structure to hold all of the files and configurations related to the Certificate Authority (CA).  We'll create subfolders for certscrlnewcerts, and private.  Note, we need to apply fairly restrictive permissions to these directories given the sensitive nature of the CA when the generated certificates are used for Authentication and Authorization.  
    sudo mkdir /root/ca/intermediate/VPN/certs
    sudo mkdir /root/ca/intermediate/VPN/crl
    sudo mkdir /root/ca/intermediate/VPN/csr
    sudo mkdir /root/ca/intermediate/VPN/newcerts
    sudo mkdir /root/ca/intermediate/VPN/private
    sudo chmod 700 /root/ca/intermediate/VPN/private

    • OpenSSL uses the index.txt and serial files as a flat file database.  We need to create both files, and create the serial file with an initial value of 1000 inside the file.
    sudo touch /root/ca/intermediate/VPN/index.txt
    sudo nano /root/ca/intermediate/VPN/serial


    • Now, we'll copy our OpenSSL configuration file from the root CA into our new intermediate CA.  Most of the options will be the same, so copying the existing configuration will save time and prevent errors in recreating the file.  Once we've copied it over, we'll use nano to edit the contents.  I've attached a sample copy of the configuration file at the end of this lesson.
    sudo cp /root/ca/openssl.cnf /root/ca/intermediate/VPN/openssl.cnf
    sudo nano /root/ca/intermediate/VPN/openssl.cnf

    • With the file opened for editing, let's change the following lines under the [ CA_default ] section:
      • Note -- while the tutorial I followed had me name each private key, certificate, etc. with the name of the intermediate CA (VPN), in reflection I would likely have left these unchanged or used something like iCA instead to make it very clear that these are part of the intermediate CA and not just an object that it generated.
    dir                                  = /root/ca/intermediate/VPN
    private_key                          = $dir/private/VPN.key.pem
    certificate                          = $dir/certs/VPN.cert.pem
    crl                                  = $dir/crl/VPN.crl.pem
    policy                               = policy_loose


    • Great work, now that the configuration file is complete, we need to create the intermediate key which will allow us to issue trusted certificates.  It is important that this key pair is closely guarded as a compromise would result in a fundamental compromise of the Public Key Infrastructure (PKI) we are creating with this CA.  We will be protecting it by generating it with AES-256 bit encryption and a strong password and issuing restrictive file level permissions.  Additionally, we'll use a 4096-bit key length within the certificate to safeguard any certificates it generates.
    sudo openssl genrsa -aes256 -out /root/ca/intermediate/VPN/private/VPN.key.pem 4096
    <password>
    <password>
    sudo chmod 400 /root/ca/intermediate/VPN/private/VPN.key.pem

    • With the intermediate key created, we need to create a certificate signing request (CSR).  We'll use the same details as the root CA, but the Common Name will be unique.  Note -- we need to make certain we specify the Intermediate CA configuration file (/root/ca/intermediate/VPN/openssl.cnf) and not the root CA configuration file.  Note, for the Organizational Unit Name and Common Name, ensure this is the name you want to use for the Intermediate Certificate Authority.
    sudo openssl req -config /root/ca/intermediate/VPN/openssl.cnf -new -sha256 -key /root/ca/intermediate/VPN/private/VPN.key.pem -out /root/ca/intermediate/VPN/csr/VPN.csr.pem
    <Intermediate CA Password (from the previous step)>
    <Your CA / Organizational details>
    sudo chmod 444 /root/ca/intermediate/VPN/private/VPN.key.pem



    • Good, we have our signing request generated.  Now, we need to create an intermediate certificate using the root CA.  Note -- we need to make certain we specify the root CA configuration file (/root/ca/openssl.cnf) and not the Intermediate CA configuration file.  
    sudo openssl ca -config /root/ca/openssl.cnf -extensions v3_intermediate_ca -days 7200 -notext -md sha256 -in /root/ca/intermediate/VPN/csr/VPN.csr.pem -out /root/ca/intermediate/VPN/certs/VPN.cert.pem
    <Root CA Password>
    y
    y
    sudo chmod 444 /root/ca/intermediate/VPN/certs/VPN.cert.pem

    • Let's make sure the root CA registered the signature process.  To do this, we need to look in the index.txt file of the root CA using the cat command.  Review any entries to ensure our new intermediate CA is listed.
    sudo cat /root/ca/index.txt

    • Good -- we know the certificate was signed, now let's check that the details of the cert look correct using OpenSSL.  Validate the details to ensure they align with your inputs.
    sudo openssl x509 -noout -text -in /root/ca/intermediate/VPN/certs/VPN.cert.pem

    • OK -- now that we know the details look good, let's validate the intermediate CA cert against the root cert to ensure the chain of trust is intact.  If we get a response of "OK" we know everything worked.
    sudo openssl verify -CAfile /root/ca/certs/ca.cert.pem /root/ca/intermediate/VPN/certs/VPN.cert.pem

    • When applications validate certificates, they need to validate the full certificate chain -- including the root certificate.  In our case, this can be done either by installing the root certificate on every client (ideal if you run your own intranet) or by including the root in the chain.  In this example, we'll include the root in the chain because a number of devices (think phones, IP webcams, etc.) do not always allow us to install the root certificate.  So -- let's create our certificate chain with both our intermediate and root certificate like this (note, for some reason this doesn't always work well with sudo, so I sudo su'd to root for these commands):
    cat /root/ca/intermediate/VPN/certs/VPN.cert.pem /root/ca/certs/ca.cert.pem > /root/ca/intermediate/VPN/certs/ca-chain.cert.pem
    chmod 444 /root/ca/intermediate/VPN/certs/ca-chain.cert.pem

    • Perfect -- just one more step.  We need to generate our Diffie-Hellman parameters.  Some applications will use these to increase the security of the key exchange.  In this step, we'll generate the parameter file, but show later, in the server and client certificate tutorials, how to include these in our certificates.  Generating the parameters is easy -- just issue the below command.  One note, similar to key strength, we'll use 2048 bit strength since this will be used in a key exchange, but you can also use stronger (4096) for better security or weaker (1024) for better performance. 
      • Note -- the process to generate the parameters is very very slow; so be patient.
    sudo openssl dhparam -out /root/ca/intermediate/VPN/certs/dh2048.pem 2048
    sudo chmod 444 /root/ca/intermediate/VPN/certs/dh2048.pem 

    • Congratulations!  Your Intermediate Certificate Authority is now configured and ready to go!  

    RaspberryPi 220 - Implementing a Certificate Authority (CA)

    posted Nov 14, 2015, 7:56 AM by Joshua S   [ updated Nov 29, 2015, 7:03 PM ]

    This tutorial will implement a Certificate Authority (CA) using the builtin OpenSSL framework.  This CA will be local and untrusted (self signed) in the broader web of trust, but should work well for the systems we are standing up locally.

    A Certificate Authority will allow us to issue certificates on our local domain for a number of reasons including implementing a VPN, encrypting LDAP and other sensitive communication, and loading into embedded devices (routers, IP cameras, etc.).  While this lesson covers establishing the CA; there will be future lessons exploring how to issue certificates and use the CA.

    To give credit where credit is due; this lesson is based heavily off of both this lesson and this lesson from others.  For a really good overview of the concepts behind CAs and PKI, check out this post.

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry
    • First things first, we need to create a directory structure to hold all of the files and configurations related to the Certificate Authority (CA).  In this case, we'll start with /root/ca and create subfolders for certs, crl, newcerts, and private.  Note, we need to apply fairly restrictive permissions to these directories given the sensitive nature of the CA when the generated certificates are used for Authentication and Authorization.  
    sudo mkdir /root/ca
    sudo mkdir /root/ca/certs
    sudo mkdir /root/ca/crl
    sudo mkdir /root/ca/newcerts
    sudo mkdir /root/ca/private
    sudo chmod 700 /root/ca/private

    • OpenSSL uses the index.txt and serial files as a flat file database.  We need to create both files, and create the serial file with an initial value of 1000 inside the file.
    sudo touch /root/ca/index.txt
    sudo nano /root/ca/serial


    • Now, let's use nano to create the file with the Certificate Authority default configurations.  I've attached a sample copy of the configuration file at the end of this lesson.
    sudo nano /root/ca/openssl.cnf

    • With the file created, let's add our header and CA sections:
    # OpenSSL root CA configuration file

    [ ca ]
    # 'man ca'
    default_ca = CA_default

    [CA_default ]
    # Directory and file locations
    dir                                  = /root/ca
    certs                                = $dir/certs
    crl_dir                              = $dir/crl
    new_certs_dir                        = $dir/newcerts
    database                             = $dir/index.txt
    serial                               = $dir/serial
    RANDFILE                             = $dir/private/.rand

    # The root key and root certificate
    private_key                          = $dir/private/ca.key.pem
    certificate                          = $dir/certs/ca.cert.pem

    # For certificate revocation lists
    crlnumber                            = $dir/crlnumber
    crl                                  = $dir/crl/ca.crl.pem
    crl_extensions                       = clr_ext
    default_crl_days                     = 30

    # Additional configurations
    default_md                           = sha256
    name_opt                             = ca_default
    cert_opt                             = ca_default
    default_days                         = 3650
    preserve                             = no
    policy                               = policy_strict


    • With the CA sections defined, it's time to lay out the Policy sections.
    [ policy_strict ]
    # The root CA should only sign intermediate certificates that match
    # See the POLICY FORMAT section of 'man ca'
    countryName                          = match
    stateOrProvinceName                  = match
    localityName                         = match
    organizationName                     = match
    organizationalUnitName               = optional
    commonName                           = supplied
    emailAddress                         = optional

    [ policy_loose ]
    # Allow the intermediate CA to sign a more diverse range of certificates
    # See the POLICY FORMAT section for the 'ca' man page
    countryName                          = optional
    stateOrProvinceName                  = optional
    localityName                         = optional
    organizationName                     = optional
    organizationalUnitName               = optional
    commonName                           = supplied
    emailAddress                         = optional


    • Now that we have the Policy sections created, it's time to create the Req sections:
    [ req ]
    # Options for the 'req' tool ('man req')
    default_bits                         = 2048
    distinguished_name                   = req_distinguished_name
    string_mask                          = utf8only
    default_md                           = sha256
    x509_extensions                      = v3_ca

    [ req_distinguished_name ]
    # See <https://en.wikipedia.org/wiki/Certificate_signing_request>
    countryName                          = Country Name (2 letter code)
    stateOrProvinceName                  = State or Province Name
    localityName                         = Locality Name
    0.organizationName                   = Organization Name
    organizationalUnitName               = Department Unit Name
    commonName                           = Common Name
    emailAddress                         = Email Address

    # Optional, default values
    countryName_default                  = GB
    stateOrProvinceName_default          = England
    localityName_default                 = London
    0.organizationName_default           = AcademicDabbling
    #organizationalUnitName_default       = 
    emailAddress_default                 = Joshua@AcademicDabbling.Com



    • Good, the Req section is complete -- now let's create the X509v3 configuration sections:
    [ v3_ca ]
    # Extensions for a typical CA ('man x590v3_config')
    subjectKeyIdentifier                 = hash
    authorityKeyIdentifier               = keyid:always,issuer
    basicConstraints                     = critical, CA:true
    keyUsage                             = critical, digitalSignature, cRLSign, keyCertSign

    [ v3_intermediate_ca ]
    # Extensions for a typical intermediate CA ('man x509v3_config')
    subjectKeyIdentifier                 = hash
    authorityKeyIdentifier               = keyid:always,issuer
    basicConstraints                     = critical, CA:true, pathlen:0
    keyUsage                             = critical, digitalSignature, cRLSign, keyCertSign

    • The X509v3 configuration sections are now finished, let's add the configuration for our User Certificates:
    [ usr_cert ]
    # Extensions for client configurations ('man x509v3_config)
    basicConstraints                     = CA:FALSE
    nsCertType                           = client, email
    nsComment                            = "OpenSSL Generated Client Certificate"
    subjectKeyIdentifier                 = hash
    authorityKeyIdentifier               = keyid,issuer
    keyUsage                             = critical, nonRepudiation, digitalSignature, keyEncipherment
    extendedKeyUsage                     = clientAuth, emailProtection

    • The User Certificate configuration is done, now let's add the configuration for the Server Certificates:
    [ server_cert ]
    # Extensions for server certificates ('man x509v3_config')
    basicConstraints                     = CA:FALSE
    nsCertType                           = server
    nsComment                            = "OpenSSL Generated Server Certificate"
    subjectKeyIdentifier                 = hash
    authorityKeyIdentifier               = keyid,issuer:always
    keyUsage                             = critical, digitalSignature, keyEncipherment
    extendedKeyUsage                     = serverAuth

    • OK -- let's finish it up with the CRL and OCSP configurations:
    [ crl_ext ]
    # Extension for CRLs ('man x509v3_config')
    authorityKeyIdentifier=keyid:always

    [ ocsp ]
    # Extension for OCSP signing certificates ('man ocsp')
    basicConstraints                     = CA:FALSE
    subjectKeyIdentifier                 = hash
    authorityKeyIdentifier               = keyid,issuer     
    keyUsage                             = critical, digitalSignature
    extendedKeyUsage                     = critical, OCSPSigning

    • Great work, now that the configuration file is complete, we need to create the root pair which will allow us to issue trusted certificates.  It is important that this key pair is closely guarded as a compromise would result in a fundamental compromise of the Public Key Infrastructure (PKI) we are creating with this CA.  We will be protecting it by generating it with AES-256 bit encryption and a strong password and issuing restrictive file level permissions.  Additionally, we'll use a 4096-bit key length within the certificate to safeguard any certificates it generates.
    sudo openssl genrsa -aes256 -out /root/ca/private/ca.key.pem 4096
    <password>
    <password>
    sudo chmod 400 /root/ca/private/ca.key.pem

    • OK, with the root key created, we can create the root certificate.  Every certificate gets an expiration date, but for this certificate, we should choose a very long time -- perhaps 20 years.  The reason this is important, is that when the root certificate expires, then all certificates signed by the root will also expire.
    sudo openssl req -config /root/ca/openssl.cnf -key /root/ca/private/ca.key.pem -new -x509 -days 7300 -sha256 -extensions v3_ca -out /root/ca/certs/ca.cert.pem
    <CA Password (from the previous step)>
    <Your CA / Organization specific details>
    sudo chmod 444 /root/ca/certs/ca.cert.pem

    • Perfect, we're almost there.  With the root certificate created, we can now verify the cert to make sure everything was generated correctly.  We are verifying the:
      • Signature algorithm
      • Dates of validity
      • Public-Key bit length
      • Issuer (Identical to Subject)
      • Subject (Identical to Issuer)
    sudo openssl x509 -noout -text -in /root/ca/certs/ca.cert.pem

    • Congratulations!  Your Certificate authority is now configured and ready to go!  

    RaspberryPi 112 - Configuring the Login Banner

    posted Nov 12, 2015, 6:34 PM by Joshua S

    This tutorial will customize the login banner of the RaspberryPi.  This can be a good way to display basic information about the Pi each time a user logs in.  In this case, we'll use it to include the name, IP address, and purpose of the Pi, but you can include whatever you consider to be meaningful.

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry
    • OK, good!  Now that everything is updated, let's edit the /etc/motd file using nano.  While you can replace the entire message, I elected to leave the default message intact and add my custom message to the bottom:
    sudo nano /etc/motd


    • With the message customized, you're all set.  Let's reboot and log back in to see the message.
    • It works!  Congratulations, your login message is updated!

    RaspberryPi 302 - Installing RetroPi

    posted Nov 11, 2015, 4:28 PM by Joshua S   [ updated Nov 11, 2015, 4:32 PM ]

    This post demonstrates how to build a RetroPi from scratch.  The good people over at RetroPi built an amazing use case of the RaspberryPi that lets us play all of our favorite old video games (ROMs not included) from our RaspberryPi!  In the end, this will be an amazing gaming machine!

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!


    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    • ROMs   IANAL (I am not a lawyer), but my understanding is that ROMs are legal digital copies of video games which you already own.  I assume there are about 12,000 layers of legal complexity here which are far outside the scope of this Dabble.  You will need these files to use the RetroPi Dabble.  Rumor has it, you may be able to find these files online for free, but again, IANAL, and can't speak to the legal implications of downloading them.

    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the pi username and builtin account.  It is important to use the pi account for purposes of this lesson as HomeAssistant will run under the pi account.  If you have not updated the password, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry
    • OK, good!  Now that we are connected, let's install let's in
    • OK, good!  Now that everything is updated, let's install GIT functionality.  Use the following commands:
    sudo apt-get -y install git dialog
        • git  Fast, scalable, distributed revision control system.
        • dialog  Displays user-friendly dialog boxes from shell scripts.

    • Now we'll use git to download the latest version of the RetroPi startup script using the following commands:
    git clone git://github.com/petrockblog/RetroPie-Setup

    • Run the RetroPi setup script using the below command and follow the presented prompts as noted in the following screens:
    cd RetroPie-Setup
    sudo ./retropie_setup.sh














    • Congratulations!  Your RetroPi is up and running!

    RaspberryPi 104 - Adding a Network Connection (WiFi - EDiMAX EW-78811Un)

    posted Nov 10, 2015, 8:33 AM by Joshua S   [ updated Nov 11, 2015, 2:16 AM ]

    This tutorial demonstrates how to add WiFi functionality to a RaspberryPi.  This will be very helpful when you want to use a Pi in a location not located directly next to the router or with an available LAN cable.

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    • WiFi Module  There are a number of USB modules compatible with the RaspberryPi.  In this case, we're using the EDiMAX EW-78811Un.
    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry

    • First things first, let's run the ifconfig command to make sure all of our drivers are set up.  If you see a wlan0 section, then you know the drivers and hardware is functioning but not configured.  If you do not see this section, there is a hardware or driver issue.  
    • If there are issues, try working through the "Problems?" section of this site.
    sudo ifconfig

    • Many network related settings can be found in your /etc/network/interfaces configuration.  Navigate to this file and open it to edit with Nano. 
    sudo nano /etc/network/interfaces


    • Note -- your wired connection is configured in the first "eth0" section.  The Add (or update) the wlan0 (wireless) section with the following lines.  Note -- this assumes you are running WPA2 (I haven't tried it with any others).  
    allow-hotplug wlan0 (remove)
    auto wlan0 (add)
    iface wlan0 inet dhcp
    wpa-ssid "<WiFi Name>"
    wpa-psk "<Password>"

    • Now that the config is complete, we need to cycle the wireless network in order to connect.  Use the following commands:
    sudo iwconfig 
        • Shows the network is still not set up
    sudo ifup wlan0 
        • Gets the wifi card ready to configure
    sudo ifdown wlan0
        • Takes down the wifi card
    sudo ifup wlan0 
        • Brings up the wifi card and begins the process to connect
    sudo iwconfig 
        • Shows the network is set up and has an IP address assigned
    sudo ifconfig 
        • Shows the network has an IP address assigned

    • Congratulations!  You have now WiFi'd your Pi!

    RaspberryPi 130 - Adding Storage (USB)

    posted Nov 6, 2015, 1:55 PM by Joshua S   [ updated Nov 26, 2016, 4:48 AM ]

    This tutorial will first mount a USB flash drive and then demonstrate how to auto-mount the drive if you wish to use it as permanent storage for the Pi.

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    • USB Flash Drive data storage device that includes flash memory with an integrated Universal Serial Bus (USB) interface. USB flash drives are typically removable and rewritable, and physically much smaller than an optical disc. 
    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry
    • OK, good!  Now that everything is updated, let's find our USB stick.  Note, the disks starting with the name "mmc" refer to the SD Card.  Any USB devices should be noted as starting with "sd" similar to the one found here of "sda".  Use the following commands:
    ls -al /dev/disk/by-uuid/







    • Note the hardware ID of the drive -- we'll need it later when we permanently mount it.  In this example (see the previous picture), the ID is F498AB4098AAFFEA.
    • In our example, we see our drive has uuid sda1.  Let's start by formatting the drive.  In this case, we'll use EXT4 -- it is a native Linux format which allows large file size and delivers good performance.  Here are a list of potential file system formats as you consider the right one for your use.  Note, the -L argument allows us to put a label on the drive -- in this case I gave the label "storage".  Use the following commands:
    sudo mkfs.ext4 /dev/sda1 -L storage

    • Good job!  Now that the drive is formatted, we need to create the "mount point".  Basically, this will be the directory where we attach the file system of the USB stick.  This is an important difference between Windows and Linux -- as opposed to having drive letters, like in Windows, Linux mounts drives within directories based upon configuration.  Use the following command to create the mount point and provision it appropriate permissions:
    sudo mkdir /mnt/storage
    sudo chmod 770 /mnt/storage

    • Let's start by mounting the drive for this session, but then we'll add the config needed to automatically mount the drive when the RaspberryPi reboots.  To mount for this session use the following command:
    sudo mount -t ext4 /dev/sda1 /mnt/storage

    • Great!  The USB stick is now mounted for this session.  To have it automatically mount, we'll need to edit the FSTab, or file system table, file.  Let's backup the file, just in case we cause issues, then edit it using these commands:
    sudo cp /etc/fstab /etc/fstab.backup
    sudo nano /etc/fstab

    • Within the file, add the following line (see the before and after images below).  This will allow the drive to auto-mount when we reboot.
    UUID=<Drive UUID from above> /mnt/storage ext4 defaults 0 0


    • Let's reboot now and make sure our changes worked:
    sudo reboot

    • When the system finishes rebooting, log back on, and use this command to navigate to the drive.  If everything worked as expected, you should be able to navigate there with no errors and issue an ls command against the directory.  Note, since we mounted this using default options, all permissions will be restricted to root -- for this reason, we are going to first switch to root.  Depending on how you plan to use this drive, you may want to alter the permissions appropriately.
    sudo su
    cd /mnt/storage
    ls -al

    • Congratulations!  Your drive is mounted and will automatically re-mount each time the Pi boots.

    RaspberryPi 122 - Connecting the Samba Client

    posted Nov 4, 2015, 2:23 AM by Joshua S   [ updated Nov 12, 2015, 3:57 PM ]

    This tutorial will connect to a Samba.  This will allow for centralized authentication and authorization with integration into Windows and SMB protocols.

    LDAP (Lightweight Directory Access Protocol) allows for central authorization (UserIDs and Passwords) and authorization (Security Groups), along with a number of other centralized management functions such as distribution lists.  

    With any of the Dabbles on this site, if you have questions, suggestions, or thoughts, please feel free to send me an eMail (I'm still working to figure out how to enable comments on Google Sites -- suggestions would be appreciated)!

    Supply List:
    • RaspberryPi  The actual RaspberryPi hardware this will all be built around.  In this tutorial, a Raspberry Pi 2 is used and has a memory card with the Raspbian operating system pre-installed.
    • PuTTY SSH Client – PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection.  Other SSH tools can be used, but this tutorial will leverage PuTTY.
    Prerequisites:

    Project:
    • I know I said this guide was going to be comprehensive and not skip any steps, so what better way to start this off than by skipping steps.  I am not writing out instructions for the following (and illustrating from XKCD):
      • Buying a MicroSD Card
      • Buying a RaspberryPi 
      • Finding the IP Address of your Pi
        • This can be done in many ways, including on your router or using an IP scanner such as (AngryIP Scanner or NMAP) -- if there are requests from the "Contact Me" form; I'll look to create a tutorial for this.
      • Obtaining and installing PuTTY
    https://xkcd.com/1343/
    • Using PuTTY (or the SSH client of your choice) enter the IP Address or DNS Name of the RaspberryPi.
    • If this is the first time you connect, you will get a warning that the RaspberryPi's host key is unknown.  Click "Accept" or "Connect Once" to proceed with the connection.
    • Once connected, log onto the Pi using the credentials you created.  If you have not defined your own credentials, you should, but these are the default credentials:
    • UserID:  pi 
    • Password:  raspberry
      • Now let's install the samba client.  Use the following commands:
      sudo apt-get -y install smbclient
          • smbclient  SMB/CIFS file, print, and login client for Unix.
        • With Samba installed, let's configure the client.  Use Nano to edit the /etc/samba/smb.conf file and update the following lines.  An example file is included at the bottom of this lesson.
        sudo nano /etc/samba/smb.conf

        workgroup = <samba workgroup>


        • Congratulations!  Your Client is now configured to integrate with the Samba server! 

        1-10 of 33

        Comments