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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
- Provision the Root Certificate Authority (CA). You will need this before you can create an Intermediate Certificate Authority. For a tutorial to do this, try:
- Provision the Intermediate Certificate Authority. You will need this to sign actual server and client certificates. For a tutorial to do this, try:
- Understand how to provision Server and Client certificates which will be used in this dabble.
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
- 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>
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"
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"
tls-auth /etc/openvpn/keys/ta.key 0
status /var/log/openvpn-status.log 20
- 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
- With these changes configured, we need to apply them using the following command:
- 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
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!
|
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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
- Provision the Root Certificate Authority (CA). You will need this before you can create an Intermediate Certificate Authority. For a tutorial to do this, try:
- Provision the Intermediate Certificate Authority. You will need this to sign actual server and client certificates. For a tutorial to do this, try:
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
- 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
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>
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.
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!
|
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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
- Provision the Root Certificate Authority (CA). You will need this before you can create an Intermediate Certificate Authority. For a tutorial to do this, try:
- Provision the Intermediate Certificate Authority. You will need this to sign actual server and client certificates. For a tutorial to do this, try:
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
- 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>
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.
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!
|
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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
- Provision the root certificate authority. You will need this before you can create an Intermediate Certificate Authority. For a tutorial to do this, try:
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
- 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 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/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
- 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
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
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!
|
posted Nov 14, 2015, 7:56 AM by Joshua S
[
updated Nov 29, 2015, 7:03 PM
]
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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
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
- 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/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
# Directory and file locations
new_certs_dir = $dir/newcerts
database = $dir/index.txt
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
# Additional configurations
- With the CA sections defined, it's time to lay out the Policy sections.
# The root CA should only sign intermediate certificates that match
# See the POLICY FORMAT section of 'man ca'
stateOrProvinceName = match
organizationalUnitName = optional
# Allow the intermediate CA to sign a more diverse range of certificates
# See the POLICY FORMAT section for the 'ca' man page
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
- Now that we have the Policy sections created, it's time to create the Req sections:
# Options for the 'req' tool ('man req')
distinguished_name = req_distinguished_name
[ 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
emailAddress = Email Address
# Optional, default values
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:
# Extensions for a typical CA ('man x590v3_config')
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
# 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:
# 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:
# Extensions for server certificates ('man x509v3_config')
basicConstraints = CA:FALSE
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:
# Extension for CRLs ('man x509v3_config')
authorityKeyIdentifier=keyid:always
# 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
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!
|
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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
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
- 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:
- 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!
|
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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Configure a DNS server to allow for name based addressing which is managed centrally. For a tutorial to do this, try:
- Configure an LDAP server to allow for centralized authentication and authorization which is managed centrally. For a tutorial to do this, try:
- Configure an LDAP client on the Pi to allow for centralized authentication and authorization -- managed centrally.
- Configure a Samba server to allow for SMB integration. For a tutorial to do this try:
- Configure a Samba client to allow for SMB access. For a tutorial to do this try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
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
- 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.

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:
- Congratulations! Your RetroPi is up and running!
|
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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
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
- 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.

- 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)

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


- Congratulations! You have now WiFi'd your Pi!
|
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)!
- 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 – A 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
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
- 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 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
- 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:
- 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.
- Congratulations! Your drive is mounted and will automatically re-mount each time the Pi boots.
|
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)!
- 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: - Install Raspbian on a memory card for the Raspberry Pi – for a tutorial to do this, try:
- Configure Raspbian so the basic setup is complete. For a tutorial to do this, try:
- Shrink the Raspbian operating system to remove unused components thus increasing efficiency and decreasing the attack surface. For a tutorial to do this, try:
- Configure a DNS server to allow for name based addressing which is managed centrally. For a tutorial to do this, try:
- Configure an LDAP server to allow for centralized authentication and authorization which is managed centrally. For a tutorial to do this, try:
- Configure an LDAP client on the Pi to allow for centralized authentication and authorization -- managed centrally.
- Configure a Samba server to allow for SMB integration. For a tutorial to do this try:
- Update Raspbian to the latest software versions. This should be periodically and prior to making any changes to the RaspberryPi. For a tutorial to do this, try:
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
- 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!
|
|