raspberrypise

[raspberrypise]

Raspberry Pi Display Options

Choosing a Display for your RPi

Author: Jacobm001

We get a lot of questions on the Raspberry Pi stackexchange about display types. Between the GPIO, DSI, and HDMI port, there are no shortage of options. Understanding the various benefits and drawbacks of each is important if you want to make an informed choice on screen types. So, here is a brief rundown of the most popular choices available.

GPIO Screens

Screens that connect to the Raspberry Pi through its GPIO are very popular for applications that tend to utilize little screen space. If you're looking to create something like an alarm clock or a weather station, these are often a great choice.

GPIO screens are inexpensive, take little room, and usually require no additional wires. This makes them easy to build into enclosures and are generally less cluttered.

Unfortunately, these screens require kernel modules to operate. That means that once purchased, your RPi needs to run a supported kernel version for as long as you plan on using the screen. That may not be a big deal for your project, but if you need or want the bleeding edge, these may not be a good option for you.

HDMI Displays

If you're looking to create a sign, kiosk, or other large display, an HDMI display is probably going to be your best bet. They tend to be more expensive, but are usually more polished and offer much larger sizes and higher resolutions.

A big downside to using an HDMI display is that they're going to cost significantly more. While the GPIO screens previously mentioned can often be gotten for $30-40, an HDMI display will often run at least $80. Additionally, you'll need to worry about a bulky cable and another power cord.

DSI Displays

A someone lesser known option for the Raspberry Pi is its DSI output. At the time of this writing, the official offering is the only choice (as far as the author is aware) if you wish to use the DSI port.

While more expensive than most of the GPIO options, it is less expensive than most HDMI displays, and offers touch capabilities. While it's significantly less bulky, the only DSI display offered is at 800x480. Larger than most GPIO offerings, but a far cry from an HD HDMI display.

Composite and USB

In addition to the other displays mentioned the RPi is also capable of displaying video through a composite connection. This may be handy if you have an old TV lying around, but if you're going to buy a new display, I wouldn't recommend choosing composite. The offerings I've seen tend to be relatively expensive, and offer little advantage over the alternatives.

Finally, I've seen a couple displays using USB. While it's a possible choice, I wouldn't recommend it. I've seen several questions on StackExchange that boiled down to USB bottle necks. My personal experience suggests that if you want to use a USB screen and a heavy network load, you'll run into issues.

So, Which Type for You?

As often as I've seen/heard this question, there's really no good rule of thumb here. No one screen type will fit every project, and you'll have to weigh the benefits/drawbacks of each for your individual projects needs.

[raspberrypise]

SSH Security and Usability – Part 6

Author Steve Robillard

Passwordless logins on Windows,

Passwordless logins on Linux,

Creation of a custom login messages and SSH Prompt,

Securing our keys and agent, and

SSH server configuration

In today’s post we will look at network security using UFW, Fail2ban and TCP Wrappers.

UFW

UFW stands for uncomplicated firewall, and is a simple front end to iptables. You can allow or deny network traffic based on source, destination, host, port, protocol and service.

Note: there is a GUI for ufw called gufw. It can be installed with the following command: sudo apt install gufw. However, its use will not be covered in this post.

To install ufw:

sudo apt install ufw

Unlike most services (e.g. Apache, Etckeeper) ufw is not enabled by default after installation.

Note: To prevent being locked out of the server, due to a configuration error, you should perform these actions using a keyboard and monitor connected directly to the server.

To enable ufw:

sudo ufw enable

Note: The enable command warns you that your SSH connection may be disrupted by this and asks you to confirm the action. If this happens you will need physical access to login and reestablish SSH access.

UFW comes with a default profile, which blocks most incoming traffic and provides a good starting point. You can check the status of ufw and view the default rules with the following command:

sudo ufw status verbose

However, this default profile will not allow connections on the custom SSH port (2332) we set in the last post.

To allow SSH traffic to the new port you can use the following command:

sudo ufw allow 2332

Check the new rule:

sudo ufw status verbose

Note: ufw will automatically generate two rules one for IPv4 and one for IPv6.

This rule will work, but it opens a bigger hole than is necessary. When it comes to security you want to apply every possible constraint to limit your attack surface. One problem with the above rule is that it allows UDP connections to our custom SSH port (2332). As I mentioned in the last post SSH only uses TCP.

Remove the previous rule:

sudo ufw delete allow 2332

Note: to delete an existing rule add "delete" after ufw to the command you used to add the rule, or use the following command to list the rules by number:

sudo ufw status numbered

and then remove the rule with the following command:

sudo ufw delete #

Replacing the # in the above command with the number of the rule you want to delete.

You can verify the change with the following command:

sudo ufw status verbose

We can replace the previous rule with:

sudo ufw allow 2332/tcp

and verify it with:

sudo ufw status verbose

You should now be able to establish a new SSH connection to your server using port 2332. If you only need access to your server from a specific IP address or range of IP’s you can replace the above rule with one that specifies which IP address or range of addresses can connect.

To allow a specific IP address:

sudo ufw allow from 192.168.1.85 to any port 2332 proto tcp

And for a range of IP’s:

sudo ufw allow from 192.168.1.0/24 to any port 2332 proto tcp

Change the above rules to match your network configuration.

Note: unlike the previous rules this will only create one rule (IPv4). If you need a rule to support IPv6 you will need to create it yourself, by replacing the IPv4 address or range in the above command with the proper IPv6 address or range.

We can protect against brute force login attacks, by limiting the number of connections made to our server in the last thirty seconds, from the same IP address. Because, we are using passwordless logins this rule’s main value is in limiting the noise sent to the log files by an automated attack. To limit connection attempts to our SSH server, add the following rule to ufw:

sudo ufw limit proto tcp from any to any port 2332

This will allow no more than 6 connections in a 20 second time period.

Fail2ban

Fail2ban monitors your log files for signs of an attack and dynamically adds firewall rules to block the attacker. It also removes those rules after a set period of time.

To install fail2ban:

sudo apt install fail2ban

Fail2ban comes with a default config file (/etc/fail2ban/jail.conf). Because this file can be modified by a subsequent package update, it is suggested that you create a /etc/fail2ban/jail.local file and add your local config changes to the new file.

Create the /etc/jail.local file:

sudo nano /etc/fail2ban/jail.local

and add the following to it:

# Fail2Ban configuration file. # Comments: use '#' for comment lines and ';' for inline comments [DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = 192.168.1.0/24 # "bantime" is the number of seconds that a host is banned. bantime = 900 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 maxretry = 3 # Destination email address used solely for the interpolations in # jail.{conf,local} configuration files. destemail = pi@localhost # # ACTIONS # # email action. Since 0.8.1 upstream fail2ban uses sendmail # MTA for the mailing. Change mta configuration parameter to mail # if you want to revert to conventional 'mail'. mta = mail # # JAILS # [ssh] enabled = true port = ssh filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] logpath = /var/log/auth.log [ssh-ddos] enabled = true port = ssh filter = sshd-ddos action = iptables[name=SSH, port=ssh, protocol=tcp] logpath = /var/log/auth.log maxretry = 10

Note: change the above IP range, email address and MTA as needed to match your settings.

This file and the jail.conf file it is based on are well commented, but there are a few things to note in the above:

At present fail2ban only supports IPv4. IPv6 support is expected in the next major release.

ignoreip = 192.168.1.0/24 this will prevent fail2ban from blocking traffic from your local network, You can alternatively supply a single IP address.

If you did not edit your /etc/services file after changing the port SSH listens on. The above will not work. Either change the /etc/services file or replace port = ssh with port = ####, where #### is your SSH port.

Note: you only need to include the settings you want to override to the jails.local file. Default options will be taken from the jails.conf file.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart fail2ban:

sudo service fail2ban

Verify it is working:

sudo tail -f /var/log/fail2ban.log

Tip: If you want to test that fail2ban is working correctly, banning and unbanning connections, you can edit the /etc/fail2ban/jail.local file and comment out (insert a “#” at the beginning of the line) the following line: ignoreip = 192.168.1.0/24. Then try connecting to your server with a nonexistant username. If you tail the logs you should see a warning for each unsuccessful connection and a ban after several unsuccessful attempts. Once the bantime expires (15 minutes) you should see an unban message in the log, and be able to connect again – with your regular username.

TCP Wrapper

TCP wrappers are used to restrict access to TCP services based on host name, IP address, or network address. Its configuration is controlled by two files: /etc/hosts.allow and /etc/hosts.deny. When a connection request for a TCP service (like SSH) is received the service checks for a rule allowing the connection in /etc/hosts.allow, if it finds one it allows the connection. If a matching rule is not found it checks the /etc/hosts.deny file and if no matching rule is found it allows the connection.

Note: Because hosts.allow is checked before hosts.deny, the allow rules have higher precedence. Each file is checked from the top down and only the first matching rule is applied.

Best practice is to whitlist connections (i.e., deny everything and add explicit exceptions where necessary). To deny everything Open the /etc/hosts.deny file in your editor:

sudo nano /etc/hosts.deny

and add the following to the end of the file:

ALL: ALL

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

To add an explicit exception open the /etc/hosts.allow file:

sudo nano /etc/hosts.allow

And add the following to the end of the file:

sshd: 192.168.1.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Change the partial IP address above to match your network configuration.

Note: the trailing dot above which will allow SSH connections from the IP range 192.168.1.0-192.168.1.255. You can also whitelist a single IP (by using a complete IP address (e.g. 192.168.1.85).

Tip: If you have physical access to the server, you can test your changes by commenting out, or temporarily removing the changes to the /etc/hosts.allow file and trying to establish an SSH connection to your server. Remember to uncomment or reapply the changes to the /etc/hosts.allow file after testing.

Note: You may be wondering why you need to bother with TCP wrappers if you configured SSH to only allow specific users, from specific IP’s, and added a firewall rule that includes a from clause. This is a well-known security principle called defense in depth, and is designed to provide redundancy in case of a failure or a successful attack against a part of the system.

While I have only covered using these services to protect SSH, all of them can be used to protect more than just SSH. I suggest you read the man page and configuration file for each to learn how to protect the rest of your network services.

Next time we will look at the crypto used by SSH.

[raspberrypise]

SSH Security and Usability – Part 5

Author Steve Robillard

In the previous post in this series we covered:

Passwordless logins on Windows,

Passwordless logins on Linux,

Creation of a custom login messages and SSH Prompt, and

Securing our keys and agent.

In today’s post we will look at hardening the server by changing the server’s configuration.

SSH Server Configuration

We can improve the security of our SSH server by modifying its configuration file /etc/ssh/ssh_config. We have already seen an example of this when we setup passwordless logins. Today we will look at changing the port number, logging, limiting logins and forwarding.

Note: To prevent being locked out of the server, due to a configuration error, you should open a second connection, or better still, have physical access to the server via a monitor and keyboard.

Tip: If not using etckeeper, you should make a copy of the file (/etc/ssh/sshd_config) before editing using the following command:

mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Change the Port Number

By default SSH listens on port 22. If your SSH server is exposed to the internet, it is only a matter of time, before you start to see probes of your SSH server in your logs. You do proactively monitor your logs don’t you? You can’t eliminate this entirely, but you can eliminate many automated scans by changing the port SSH listens on.

Note: this is a case of security through obscurity, a determined attacker will be able to locate the new port via a thorough reconnaissance. This, however, is not the only measure we will rely on to protect our SSH server, and is primarily used to improve the signal to noise ratio of our logs.

To change the port number:

open the /etc/ssh/sshd_config file in your editor:

sudo nano –c /etc/ssh/sshd_config

Tip: the –c flag enables the display of line numbers.

Locate the following (line 5):

Port 22

And change it to:

Port 2332

Note: you can change this to any unused port. You can see which ports are in use with the following command:

netstat –lat

Note: many tutorials suggest port numbers 222 and 2222; I avoid these as they are becoming more common in automated probes.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart the SSH service:

sudo service ssh restart

Test the new config by opening a new connection to the server.

Note: don’t forget to update the port number in putty or your ~/.ssh/config file, and modify your firewall as needed.

Update your /etc/services file. This file maps services to ports and protocols.

Note: this will be needed when we firewall our SSH server in the next post.

open the /etc/services file in your editor:

sudo nano –c /etc/services

Locate the following line:

ssh 22/tcp # SSH Remote Login Protocol

and change it to:

ssh 2332/tcp # SSH Remote Login Protocol

Note: there is also an entry for udp. This is historical and does not need to be changed.

c

Tip: If you have more than one network interface (e.g. Ethernet and WiFi as on the Pi 3) and are using a static IP, you can limit which interface SSH listens on by uncommenting and editing the Listen Address rule at the top of the /etc/ssh/sshd_config file (e.g. ListenAddress 192.168.1.240).

Logging

By default SSH logs to the AUTH facility of syslog, with log level info. To log failed login attempts and to make troubleshooting SSH issues easier you should change this to DEBUG. If your SSH server is exposed to the internet you may be surprised at just how many probes you receive.

To change the logging level:

open the /etc/ssh/sshd_config file in your editor:

sudo nano –c /etc/ssh/sshd_config

Locate the following (line 24):

LogLevel INFO

And change it to:

LogLevel DEBUG

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart the SSH server:

sudo service ssh restart

Logs are useless if no one reads or monitors them, but reading hundreds of lines of logs is not only tedious, but risks missing import events in a sea of data. One way to monitor your logs for important events (e.g. logins and the use of sudo) is via logwatch. Logwatch will monitor your logs for events of interest and email you a report once a day.

To install logwatch:

sudo apt update sudo apt install logwatch

You can verify logwatch works by doing a manual run:

logwatch

Note: this will print the report to the screen rather than emailing it.

Note: You may also need to change this line:

/usr/sbin/logwatch --output mail

to:

sudo /usr/sbin/logwatch --mailto pi@localhost

in the /etc/cron/daily/00logwatch file.

Beyond the scope of this post, there is much more you can do with your logs, to make them more useful and improve security. You can:

Import them into splunk which will allow searching and querying your log files.

Send them to an external logging service like papertrail or loggly. This will keep a copy that cannot be easily rewritten to hide an attack. Given enough time an attacker can bypass this, but it will be hard to hide the earliest steps taken by the attacker – which are often the most important.

Archive them to a cloud service like Amazon’s AWS S3 or Glacier.

Limiting Logins

By default SSH permits root logins. This should be disabled. You will still have access to the root account by logging in as a normal user and using sudo to gain root privileges.

To disable root logins:

open the /etc/ssh/sshd_config file in your editor:

sudo nano –c /etc/ssh/sshd_config

Locate the following (line 31):

PermitRootLogin without-password

And change it to:

PermitRootLogin no

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart the SSH server:

sudo service ssh restart

You can also allow or deny logins to specific users and groups using the DenyUsers, AllowUsers, DenyGroups, AllowGroups settings. These rules are processed in the order listed. I create a second admin user on my Pi – with all the same permissions and groups and grant them access via SSH, then block the pi user. I then assume anyone trying to login as the pi user is an attacker and block them. This approach has two benefits it can be identified easily in the logs and can be automated.

To limit which users can login via SSH:

open the /etc/ssh/sshd_config file in your editor:

sudo nano –c /etc/ssh/sshd_config

Add these lines to the end of the file:

DenyUsers pi AllowUsers srobillard

changing the username to match your setup.

Note: you can go further and limit the IP address they can connect from by adding the and @ and IP to the rule (e.g. AllowUsers srobillard@192.168.2.255 or to permit a subnet **AllowUsers srobillard@192.168.2.***)

Note: you could likewise add DenyGroups and AllowGroups rules to the end of this file.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart the SSH server:

sudo service ssh restart

Tip: you can rate limit connections and sessions which can slow down brute force attempts and help ameliorate a DOS attack. For more information see the MaxSessions and MaxStartups entries in the man page (man sshd_config 5).

Forwarding

SSH can forward a graphical application, or a port. These features can be very useful, but if unneeded they should be disabled.

To disable forwarding:

open the /etc/ssh/sshd_config file in your editor:

sudo nano –c /etc/ssh/sshd_config

Locate the following line (line 64):

X11Forwarding yes

And change it to:

X11Forwarding no

Locate the following line (line 65):

X11DisplayOffset 10

Add this line after the above line:

AllowTcpForwarding no

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart the SSH server:

sudo service ssh restart

Disconnect Idle Sessions

SSH allows you to set an idle timeout period (in seconds), after which idle sessions will be disconnected.

To disconnect idle sessions after five minutes:

open the /etc/ssh/sshd_config file in your editor:

sudo nano –c /etc/ssh/sshd_config

and add the following lines to the end of the file:

ClientAliveInterval 300 ClientAliveCountMax 0

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart the SSH server:

sudo service ssh restart

I have not mentioned several other security related settings (e.g. PermitEmptyPasswords, HostBasedAuthentication and IgnoreRHosts), because recent versions of SSH have safe default values. To see all the settings available and their default values consult the man page (man sshd_config 5)

Next time we will look at network security.

[raspberrypise]

SSH Security and Usability – Part 4

Author Steve Robillard

In part 1 of this series we looked at how to create an SSH key pair (on windows) and configure your Pi to use passwordless logins. In part 2 we showed how to create a key pair in Linux and use an ssh config file to make passwordless logins easier. Part 3 showed how to display custom messages as part of the SSH login process and modify the command prompt when using SSH. In this week’s post we will begin our look at securing SSH.

Note: this post assumes that you are using Raspbian Jessie. Though most of what we cover will be applicable to other distros.

Physical Security

All security begins with physical security. If you cannot ensure the physical security of the client and server all other attempts to secure the system are for naught. Given enough time and access to the hardware an attacker can easily compromise a system. They could install a rootkit, a compromised version of the SSH server, a key logger or simply steal your private key. The Pi’s default login configuration (auto login and well known username), small size and use of an SD card only make this easier. Complete coverage of physical security is outside the scope of this post, however I do suggest that you research this further, especially if your server is located somewhere that you do not have physical control over (like a locked room in your home). I would also suggest that you configure your Pi to require the user to login. This can be configured using the raspi-config script.

Protecting your Keys

I said this in a previous part of this series, but it bears repeating NEVER SHARE YOUR PRIVATE KEY.

In parts one and two we created a key with a length of 2048 bits. To increase the security of your key you can increase the key length. To create a key with a bit length of 4096, either change the setting in PuttyGen

or with the following command on Linux:

ssh-keygen -t rsa –b 4096

Note: You will need to upload your new key to the server for it to work (see part 1 for how to do this from Windows and part 2 for Linux instructions). After confirming the new key works, you should remove the old key from the servers** ~/.ssh/authorized_keys** file. To remove the old key:

Open the ~/.ssh/authorized_keys file in your editor:

Nano ~/.ssh/authorized_keys

Locate the correct key. Each key entry begins with ssh-rsa. Match the text string that follows with the content of your public key, and delete the cooresponding lines.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

To limit the potential damage that can result from a compromised private key you should:

Use different keys for different purposes. This ensures that if your private key is compromised that the damage is limited to a subset of all machines and services you use. For example if your AWS server login key is compromised the attacker does not also gain access to your GitHub account.

The SSH Agent

We saw, in the first two parts of this series, how to use a key pair to replace passwords for SSH logins. The use of keys improves the security of your SSH logins; key based logins are harder to crack because of their length, compared to passwords. We also saw how to use an SSH agent to avoid having to repeatedly reenter the passphrase that protects our key. The SSH agent makes using passwordless logins easier, but does have security issues of its own. For example it is possible to discover the private key and passphrase by examining the memory associated with the agent process. So what steps can you take to minimize the risks?

Unload the agent and keys when not needed (e.g. done using SSH or logging out of your account).

Never copy your private key to a machine where someone else has root.

Never use an SSH agent on a computer someone else has root or administrator privileges on.

Never forward your agent connection.

Note: Doing any of the previous three will essentially share your private key with anyone with root access to the box. However, there are also times when this may not be an option. I don’t know of a way to use a passphrase protected key without using Pageant. It may also not be possible on a computer or network supplied by your employer.

The Server’s Key Fingerprint

One thing I glossed over in the first two parts of this series was the server’s key fingerprint. The first time you connect to a host you are presented with the server’s key fingerprint and asked if you want to continue to connect.

This fingerprint is an important security feature. It is how the server identifies itself to clients, and protects against man in the middle attacks. As such you should verify this fingerprint before connecting.

Note: the best way to do this is using the keyboard connected directly to the server you want to connect to, instead of after connecting via SSH. You may want to do this as part of your initial setup and record the key fingerprints.

To check the server’s fingerprint you can use one of the following commands.

Note: You can determine which key type is being used by examining the second line of the connection prompt as shown in the image above.

for an ecdsa key:

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub

for an rsa key:

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

The output from the preceding command should match that presented by the connection prompt.

You can now type yes and complete the connection. Typing yes stores the hosts key in your ~/.ssh/known_hosts file.

In the event that a server’s key has changed (either due to a man in the middle attack or from non-threat events (e.g. rebuilding the server or regenerating the keys) you will see a warning like that seen below when trying to connect.

If you are sure this is the result of a server configuration change and not an attack. You can remove the old key entry with the following command:

ssh-keygen -f "/home/pi/.ssh/known_hosts" -R lotus

Note: change the path and hostname above to match your system. The exact command is normally contained in the warning message as seen in the image above.

and reconnect. Obviously, if the reason cannot be ascribed to server maintenance you should not continue connecting and notify the system administrator immediately. When it comes to security, err on the side of caution and assume it is an attack.

Next time we will continue looking at ways to harden your SSH server configuration.

[raspberrypise]

Securing your Raspberry Pi with Let's Encrypt

Author: Jacobm001

A lot of people use their Raspberry Pis to host a personal website for a variety of reasons. Unfortunately, lack https encryption. Without that layer of security, even a well developed CMS like Drupal, Wordpress, or Grav are highly vulnerable to network snooping, man in the middle attacks, and a variety of other concerns.

In the past, SSL certificates were expensive and difficult to maintain. Because of this, few sites used https if it wasn't absolutely necessary. In reality, a lot of sites that should have used https didn't until relatively recently.

We're not going to go into detail on how public key encryption works here. However, you should know that to make an https connection, you need a trusted third party to take part in the communications between your host and client devices. This is where the part about costing money comes in, and how a barrier to entry has recently been removed.

Let's Encrypt is a fairly new organization that provides trusted, 3rd party certificates for free. Not only do they make what was once an expensive product free, they also offer some easy, automated tools that make the process simple. At this point, Let's Encrypt is listed as a trusted source in all major web browsers.

Assumptions

If you're reading this, I'm assuming that you are already running a web server of some kind and a domain name. If you're not, you may find this article helpful.

Using Let's Encrypt

The Raspberry Pi isn't an officially supported device, but the script is written in Python, and both nginx and apache2 are supported, so you shouldn't have any problems with it. Let's Encrypt will auto install any dependencies you're missing and then give you a fairly simple prompt to follow.

Note: you will see one more screen than I have to display. Since both of my machines have letsencrypt previously installed, my administrative email address is already stored.

Download certbot-auto: wget https://dl.eff.org/certbot-auto

Make the certbot-auto script executable: chmod a+x certbot-auto

Run the script sudo ./certbot-auto

Select which of your active domains you want to enable https for. It defaults to all sites.

Select if you want to do Easy or Secure mode. Easy will allow users to enter your site through both http and https. Personally, I see no reason to allow http for anything, so I always select the Secure option.

Once that's done, you should see a screen telling you that you've succeeded. It will also give you a link you can use to test your new certifications if you wish.

Finally, you'll see a short outro telling you a little bit about the application. As always, consider donating to your favorite open source applications.

Once you've reached this part, you should be done. Try going to yoururl.com (replace with your real domain). You should automatically be redirected to https://yoururl.com. You'll need to do this again in about two and a half months, as the certificate expires every three. This can be automated, but that comes with certain security trade offs.

Further Reading:

If you would like a simpler explanation as to how public key encryption works, I'd recommend taking a look at this article. It's slightly over simplified, and cuts out the part about the trusted middle man, but is a good overview none the less.

[raspberrypise]

how does sign up for Piversify to get an email when new entries are made?

This might help http://unwrapping.tumblr.com/post/141393815712/get-notifications. Also, there is an RSS link on the right hand side of the page that you can connect to an RSS reader or with a little more work an email.

[raspberrypise]

SSH Security and Usability – Part 3

Author Steve Robillard

In part 1 of this series we looked at how to create an SSH key pair (on windows) and configure your Pi to use passwordless logins. In part 2 we showed how to create a key pair in Linux and use an ssh config file to make passwordless logins easier. In today’s post we will look at how to display custom messages as part of the SSH login process and modify the command prompt when using SSH.

Note: this post assumes that you are using Raspbian Jessie.

There are two points in the SSH connection process where you can add your own messages, before the login prompt and after a successful login. Anyone who has administrated multiple boxes has at one time logged into the wrong box and wasted time diagnosing a problem or looking for a file on the wrong machine. One of the things I do to avoid this is add an ASCII text banner to my SSH logins.

Display a Custom Message before Login

The first step is to enable this feature in the /etc/ssh/sshd_config file:

sudo nano /etc/ssh/sshd_config

Note: the d in the file name.

Locate the following line(line 72):

#Banner /etc/issue.net

And change it to:

Banner /etc/issue.net

Note: remove the leading pound sign (#). In most Linux configuration files any line that begins with a # is considered a comment and ignored. Therefore, removing the # sign is often referred to as uncommenting the line.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Next we need to edit the /etc/issue.net file.

sudo nano /etc/issue.net

This file currently contains the following text:

Raspbian GNU/Linux 8

Note: I don't find this that helpful so I remove the default text:

Ctrl-k

You can add whatever text you like to this file. On a multiuser or internet accessible box I would add a legal disclaimer and warning regarding unauthorized access and the logging policy. On my internal machines I add ASCII text of the hostname. For example Triumph (I name my machines around automobile brands).

You can generate your own ASCII text using this website. If ASCII art is more to your liking this Pi Foundation forum thread has several examples of Raspberry themed ASCII art.

Once you are happy with the contents save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Reload the SSH configuration:

sudo service sshd reload

Test Your Changes

Exit your SSH session:

Exit

And reconnect. You should see your custom message at the top of the screen.

Note: you may see an extra line similar to this: Using username “pi” if you are using putty/superputty. This comes from putty and is not controlled by your Pi.

Display a Custom Message after Successful Logins

To change the message that is displayed after a successful login, edit the /etc/motd file.

sudo nano /etc/motd

Note: This file is static and will not evaluate any included code.

Make your changes to this file - I usually just remove this text.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Test Your Changes

Exit your SSH session:

Exit

And reconnect. You should see your custom message after logging in.

Note: by default you will see the last login time and machine used to connect. For security reasons I suggest leaving this. It can alert you that a security breach may have occurred.

**Modifying the Command Prompt for SSH **

Again, anyone who has worked with multiple machines has entered the correct command on the wrong machine. In the case of SSH you might think you are running the command on your local machine instead of on the remote machine or vice versa – with potentially disastrous results. To help avoid this I modify the text and color of my SSH prompts. I color my regular SSH user logins yellow and append “ ssh” to the prompt.

Note: I use the default green prompt for local non root logins, and red for the root prompt.

To do this edit your ~/.bashrc file.

nano ~/.bashrc

append the following to the bottom of the file:

**

\### Customize the Bash prompt when accessed via SSH if [ -n "$SSH_CLIENT" ]; then text=" ssh" export PS1='\[\e[1;33m\]\u@\h:\w${text}$\[\e[m\] ' fi

**

Note: If you don’t like yellow you can replace the 33 above with one of the other Bash foreground color codes.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Note: if you implemented the conf.d style .bashrc management method I presented in my Command Line Skills Series, you can create a new file with the text from above in your .bashrc.d directory.

Test Your Changes

Exit your SSH session:

Exit

And reconnect. You should have a yellow prompt and have ssh appended to the end of it.

Next time we will begin looking at how to protect your SSH logins and hardening the SSH server.

[raspberrypise]

SSH Security and Usability – Part 2

Author Steve Robillard

In part 1 of this series we looked at how to create an SSH key pair (on windows) and configure your Pi to use passwordless logins. In today’s post we cover how to generate a key pair on Linux and how to create a ./ssh/config file to make using SSH easier.

For the purpose of this post I am going to assume that you have connected to your SSH server at least once already, and hence we won’t have to worry about debugging SSH server or connection issues.

Note: Don’t skip todays post just because you don’t have a linux box to login from, because the steps used to generate a key are the same as needed to create a key for GitHub, and the SSH config file is useful with any SSH login you may have (e.g. AWS or your webhost).

Generate a Key Pair

Note: Unlike Windows Linux will not require any additional packages be installed. From a command prompt you can generate a key pair with the following command:

ssh-keygen -t rsa –b 2048

This will generate a RSA key with 2048 bits. You can accept the default file name (enter) and location (/home/your username/.ssh/id_rsa).

Note: If this directory does not exist it will be created.

Enter a passphrase and verify it (reenter it).

Note: Do not skip this step. It may make using your key easier, but it makes your keys less secure.

Verify the directory permissions and ownership. This may seem like an unnecessary step, especially for newly created keys and directories, since the keys and folder are created if they don’t exist, but consider what happens if someone does a recursive chmod or chown or changed the default umask). Therefore I think verifying the details is just a case of due diligence. It can also save hours of troubleshooting the SSH connection issues that can result.

Switch to your home directory:

cd ~

Check the permissions and ownership:

ls –la

Your ~/.ssh directory should have read, write and execute permissions for the owner only (i.e. drwx------), and the owner and group (i.e. the third and fourth columns) should match your username.

Check the permissions and ownership of your key files.

Change to your ~/.ssh directory (note the leading dot – indicating a hidden folder)

cd .ssh

List the file permissions and ownership:

ls -la

You should see two files. Your private key id_rsa with only read and write permissions for the owner (i.e. –rw-------), and your public key id_rsa.pub with read permissions for owner, group and other and write permissions for the owner (i.e. –rw-r—r--). Both should have your username in the owner and group fields (i.e. the third and fourth columns).

Remember NEVER share or upload your private key.

Copy the Public Key to the Your SSH Server

Note: I am assuming that you have already configured your server for passwordless logins. If you have not already done so see part 1 of this series for complete instructions. To copy your key to the remote server you will need to temporarily enable password based logins first.

On your SSH server open the /etc/ssh/sshd_config file in your editor:

sudo nano /etc/ssh/sshd_config

Tip: Append –c to the above command to enable the display of line numbers.

Locate the following line (line 52): #PasswordAuthentication no

Change no to yes:

PasswordAuthentication yes

Save your changes: Ctrl-o and Enter

and exit the editor:

Ctrl-x

Reload SSH:

sudo service ssh reload

Once you have made the above changes. You can connect via SSH using your username and password on the remote machine:

ssh-copy-id user@192.168.0.100

Replace user in the above command with your username on the remote machine, and the IP Address with the IP Address or hostname of the remote machine.

So if you are trying to connect to your Raspberry Pi as the pi user you would use the following:

ssh-copy-id pi@raspberrypi.local

Tip: you can leave off the username if the username you are using is the same on both machines.

Note: if this is the first time you connect to this machine it will display the key fingerprint and ask you to confirm that you want to connect (more on this in the security post of this series).

When prompted enter your password (for the remote machine).

You should see something like the following:

Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'pi@raspberrypi.local'" and check to make sure that only the key(s) you wanted were added.

Note: the username and hostname above may be different.

End your SSH session:

exit

Verify that the key Works

Start the SSH Agent:

eval `ssh-agent`

Note: the backticks ( ` )used in the previous command – on US keyboards this is located to the left of the number 1 key.

Add your key to the SSH Agent:

ssh-add ~/.ssh/id_rsa

The above assumes you used the default keyname and location when creating your key pair, if not substitute the correct path and file name in the above command.

Tip: if you used the default name and location when creating the key pair you can omit the filename and path from the above command (i.e. ssh-add).

When prompted enter your private key’s passphrase.

You should see a message that your identity was added to the agent.

Open a new connection to your server:

ssh pi@raspberry.local

You should be logged in automatically without being prompted for a password or username.

Disable Password Authentication

Note: be sure the above works correctly before proceeding, especially if you do not have physical access to your Pi, or if it is running headless. Failure to do this can result in you being locked out of the Pi and unable to restore SSH access.

On your SSH server open the /etc/ssh/sshd_config file in your editor:

sudo nano /etc/ssh/sshd_config

Tip: Append –c to the above command to enable the display of line numbers.

Locate the following line (line 52):

#PasswordAuthentication yes

change yes to no:

PasswordAuthentication no

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart SSH:

sudo service ssh restart

Exit your SSH session:

exit

Making Logins Easier With an SSH Config File

In my post on Bash aliases I mentioned that aliases should not be used for SSH connections, as there was a better more specific method of shortening SSH commands. Instead you should create a SSH config file.

Right now we are logging in by starting the SSH Agent, adding our key to it and then using something like:

ssh username@hostname

To connect. With an SSH config file we could change that to:

ssh hostalias (i.e. ssh pi1)

Note: this may not seem like a big improvement, if you are only dealing with one or two servers, but if like me you are using SSH on multiple machines it makes life much simpler. It also makes working with non-standard SSH ports easier (I will revisit the topic of port numbers in the security part of this series). An example should make this clearer.

Switch to you ~/.ssh directory:

cd ~/.ssh

Create the file and open it in your editor:

nano config

Enter the following text:

Host YourHostAlias HostName YourHostnameOrIPAddress Port 22 User YourUsername IdentityFile ~/.ssh/id_rsa

Enter your desired host alias, IP Address or hostname, and username on the remote server. The port number and location of the identity file are set to their defaults. If these do not match your system change them as required.

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

You should now be able to login with the following:

ssh hostalias

So assuming you set your host alias to pi1 you would use:

ssh pi1

You would then be prompted for your passphrase. After entering it you should be logged in to your SSH server. No need to load your key to the SSH agent which is simpler and improves security.

Setting up paswordless logins on a Mac is likely to be very similar to that done on Linux. However, I do not have a Mac, so if someone wants to cover how to set this up on a Mac, or verify the Linux steps work please drop a comment below and let us know.

Next time we will look at customizing the login message and command line prompt when using SSH.

[raspberrypise]

SSH Security and Usability – Part 1

Author Steve Robillard

I have ten Pi’s, an Ubuntu notebook and server at home and about a dozen cloud and webhosting accounts. Most of these machines are accessed exclusively via SSH. Since so much of my work is done via SSH, I have collected a set of customizations that make SSH both more secure and usable. In this series I will show you how to:

configure SSH to use passwordless logins (from Windows and Linux),

simplify SSH connections with an SSH config file,

harden SSH,

display a custom message on SSH logins, and

customize the SSH prompt.

Configure Passwordless Logins from Windows

For the purpose of this post I am going to assume that you have connected to your Pi via SSH at least once already, and hence we won’t have to worry about debugging SSH server or connection issues.

To replace passwords we will use a public private key pair. This makes SSH logins more secure, due to their length, and with the right tooling and setup can be easier to use as well, a rare instance of a security and usability win win.

The Software

We will need an SSH client, a way to generate a public private key pair and an SSH agent. My tools of choice are PuTTY (SSH Client), PuTTYgen (Key generator) and Pagenat (SSH authentication agent). You can download either the individual tools (PuTTY, PuTTYgen and Pagenat), or the entire suite of tools. including PSCP (SCP client) as a ZIP file or Windows installer package form the download page. I suggest downloading the full suite, as it ensures that all the tools are the same version and hence compatible. I will be using the windows installer package (MSI) for this post.

Note: while the most recent version is beta 0.67 this is mature software that has been around for many years.

Download the Windows installer package, and install it.

Generate a Key Pair

From the start menu launch PuTTYgen (it is in a group called PuTTY).

Click Generate (the defaults are fine Type of key to generate: SSH-2 RSA and Number of bits in a generated key: 2048)

You will see a message instructing you to move your mouse over the blank area of the Keygen window to generate some randomness. When it finishes it will display the key and its fingerprint.

Enter a passphrase and confirm it (this is like a password for your key and should not be skipped) You will need to remember this phrase to access and use it. I suggest storing it in a password database like Keepass or [LastPass}(http://lasypass.com)

Click Save public key give it a name (i.e. PiKey.pub) and save it to your users folder (i.e. c:/users/your_username).

Note: If you have MS Publisher installed .pub files may be associated with Publisher and when clicked on will attempt to open with Publisher. You can open the file by right clicking on it and using notepad.

I keep all my keys in a .ssh folder (e.g. i.e c:/users/srobillard/.ssh).

Note: If this folder does not already exist you can create it by naming the folder .ssh. (note the trailing dot). It will be removed by Windows Explorer. Thanks to Denny on superuser.com for the solution to the naming problem.

Click Save private key give it a name (i.e. PiKey – PuTTYgen will append the .ppk file extension) and save it to the same folder as your private key.

Close PuTTYgen

Copy the Public Key to Your Raspberry Pi

Remember NEVER share or upload your private key (this is why I use the .pub file extension to name my public keys).

Launch PuTTY

Enter the Host Name (or IP address) of your Pi. Optional, but recommended (save the connection details by entering a name in the Saved Sessions text box. You can also save the username by clicking on Data from the menu on the left and entering the username in the Auto-login username testbox. Click on Session at the top of the menu, and click Save.

Click Open and enter your password when prompted.

Check for an .ssh directory in your home directory (note the leading dot):

ls –la ~

If this folder does not exist create it with the following command:

mkdir .ssh

Check the folder permissions:

ls –la ~/.ssh

If you just created this file the permissions are almost certainly wrong. This directory should only have read write access for the owner (i.e. drwx------). To change the folder permissions use the following command:

chmod 700 ~/.ssh

Verify the new permissions with another:

ls –la

Change directory to the new .ssh directory

cd .ssh

Create an authorized_keys file:

nano authorized_keys

Open your public key file with notepad (PiKey.pub).

Select all of the contents: Ctrl-A, and copy it to the clipboard Ctrl-C.

Switch back to PuTTY

Note: If the authorized_keys file already exists and is not empty (paste the new content on a separate line).

Paste the contents of the clipboard (Right Mouse Click).

Remove the following from the start of the line:

---- BEGIN SSH2 PUBLIC KEY ----Comment: "rsa-key-20160726"

Note: The number in quotes will be different for your key.

Add ssh-rsa to the beginning of the line, if it is not present.

From the end of the line remove the following:

---- END SSH2 PUBLIC KEY ----

It should look like this and be all one line when complete: ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEApLYUqh7KWXz1GhMIre4heJEJrakBgKjDBbLoKALLEMEzG1ppVnykWZa2qK2bYunrXngF0H9UHV2kX+Zji+fHoe6MWHqAWbodw5o7V/bvFjFxK3YDHzlQk8EFjYKQ2+hLVuYDvaxaXYtF/9YZLP7EUKcN2ch3ODD6KIKmMdT

Note: it wraps here because of page width.

Save the file:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Check the file permissions on the authorized_keys file:

ls –la

They should be -rw--—-—. If not use the following to change them:

chmod 644 authorized_keys

and verify the change with:

ls -la

Modify the SSHD Configuration

Open the /etc/ssh/sshd_config file in your editor

sudo nano /etc/ssh/sshd_config

Tip: Append –c to the above command to enable the display of line numbers.

locate the following lines (line 31 in my file):

RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys

And change them to (uncomment the third line):

RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart SSH:

sudo service ssh restart

Exit your putty session:

Exit

Verify that the key Works

Launch Pageant from the start menu (PuTTY group)

Right click the icon in the system tray

And select Add Key

Navigate to the location of your private key and click Open.

and enter your passphrase.

Relaunch PuTTY and your Saved Session.

Click Open to connect.

You should not be prompted for a password or username if you stored it above).

Troubleshooting

If you are prompted for a password, check the following:

Did you copy and edit the public key correctly,

Did you correctly edit the sshd_config file,

Did you restart the SSH daemon after modifying the config file,

Did you add the correct key to pageant and is it still running?

Disable Password Authentication

Note: be sure it works correctly before proceeding, especially if you do not have physical access to your Pi, or if it is running headless. Failure to do this can result in you being locked out of the Pi and unable to restore SSH access.

Launch PuTTY and login into your Pi.

Open the /etc/ssh/sshd_config file in your editor

sudo nano /etc/ssh/sshd_config

Locate the following line (line 52):

#PasswordAuthentication yes

Remove the # and change yes to no:

PasswordAuthentication no

Save your changes:

Ctrl-o and Enter

and exit the editor:

Ctrl-x

Restart SSH:

Sudo service ssh restart

Exit your putty session:

Exit

Verify Everything Works as Expected

Exit Pageant (right click the icon and choose exit).

Try to connect using Putty. You should see the following:

Disconnected: No supported authentication methods available (server sent: publickey).

Great that means passwords are not used for authentication. Now add your private key to Pageant, and try to connect with PuTTY. You should be automatically logged into your account. Congratulations, your SSH logins no longer accept passwords and your Pi is a little more secure.

Tip: You may want to look into SuperPuTTY. It is a wrapper for putty that adds several additional features including tabs and when closing your SSH session it does not require relaunching PuTTY.

Next Time we will look at how to setup passwordless SSH logins from Linux.

Setting up paswordless logins on a Mac is likely to be very similar to that done on Linux. However, I do not have a Mac, so if someone wants to cover how to set this up on a Mac, or verify the Linux steps work please drop a comment below and let us know.

[raspberrypise]

Ad Hoc Networking with Raspberry Pis

Author: shantanoo-desai

The current trends in Internet of Things lets the users connect many things over the Internet. This makes it simpler to obtain a lot of useful information without having to physically approach the devices. You can connect these so called Smart-Objects over a Wireless Medium like your WiFi and play around with the Objects. This blog post would help the new IoT Enthusiasts connecting their Raspberry Pis over WiFi without a Router.

Ad-Hoc Networks are decentralized networks, this means you do not need a central Router or Access-Points like the Infrastructure Networks. In a nutshell, every device (here, Raspberry Pis) is its own Boss. The great thing about being Ad-Hoc is the whole network becomes very flexible.

An important fact for IoT is that as the devices are going to be very large in quantity, and in order to provide connectivity to all of them, IPv6 Addresses are preferred over IPv4 Addresses. This post also supports using IPv6 Addresses on Raspberry Pis.

Requirements

Hardware : Raspberry Pi 2 Model B

Firmware : Debian Wheezy 7.10 / 7.11

USB WiFi Adapter : The current post supports using LogiLink WL0145A adapters. In general any USB Adapters with Ralink RT5370 Driver in them.

An easy way to determine this is when the Adapter is plugged in the Raspberry Pi and on the Terminal:

$ lsusb | grep -i "ralink" Bus 001 Device 004: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

Power Supply : WiFi Adapters generally need a proper power adapters. In general 2 A current ratings are essential.

Generally, such Ratings are preferred:

> Input: 100-240 V ~ 50/60 Hz 0.3A Output: 5 V - 2.1A / 5.2 V - 2.1A

Setup

Firstly backup your original interfaces file (Better be safe than sorry!)

$ cp /etc/network/interfaces /etc/network/interfaces.backup

Keep your Ethernet setting the way you like, for any Firmware/System Updates. Change your WiFi settings.

#your /etc/network/interfaces file auto lo iface eth0 inet dhcp auto wlan0 allow hot-plug wlan0

Add the ipv6 Kernel Module on startup.

$ sudo nano /etc/modules ## your /etc/modules file # add ipv6 module here ipv6

Enable SSH if not already configured.

$ sudo raspi-config

In Advanced Options -> SSH -> Enable

Automatically connect to the Pi to an Ad-Hoc network on Pi Bootup.

$ sudo nano /etc/rc.local ## inside your rc.local file adHocNetwork() { echo "Creating AdHoc Network" echo "Setting Network Parameters" ifconfig wlan0 down iwconfig wlan0 channel 6 essid name-of-network mode ad-hoc ifconfig wlan0 up } adHocNetwork exit 0

the name-of-network can be the name of your choice, channel can be value between 1 to 11 but please take care of any Access-Points near you. Do not take the same channel number as the Access-Points.

Hint : Use any one of the following [1, 6, 11] channel numbers if other two are occupied. This is beneficial to provide less intereference

Reboot your Pi.

$ sudo reboot

Once the Pi has been rebooted check your wlan0 settings using the following:

$ ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr aa:bb:cc:dd:ee:ff /etc/hostname Commit the changes using : $ sudo /etc/init.d/hostname.sh

Finally reboot your Pi and ping you Millenial Falcon from other device using the following:

$ ping6 -I wlan0 millenialfalcon.local

Control of Pis

You can now run your work on these Pis and most common functionality with Pis are SSH and SCP.

Unfortunately the mDNS names are unavailable for the SSH and SCP.

SSH

In order to avoid typing your Pi's password everytime, it preferred to make all your Pis in the network Headless.

The Official Raspberry Pi Documentation for Headless SSH will help you estabilish a passwordless entry to your Pi.

Hint : After the SSH-Key is generated you can share the key directly with the Pi using :

$ ssh-copy-id pi@fe80::axbb:ccff:fedd:eeff%wlan0

You will be asked to give the password once and then next time you will SSH into the Pi without a password.

$ ssh pi@fe80::axbb:ccff:fedd:eeff%wlan0

NOTE: please remember to use %wlan0 at the end of IPv6 Address that is important.

SCP

SCP is used to share files between your Pis.

In order to send a file to a Pi:

$ scp myFile pi@[fe80::axbb:ccff:fedd:eeff%wlan0]: /home/pi/your/folder

Note: You need the [] around your IPv6 Addresses or else there will be errors.

Hope this blog post covers the majority of things. Good Luck with creating fun Projects in Ad-Hoc Networks

[raspberrypise]

Quick Links 2

Author: SteveRobillard

Tutsplus published a great guide: Professional Error Handling with Python

Tony D. from Adafruit did a nice 4 part video series: the Raspberry Pi Talking to WiFi ‘Things’ Part 1, Part 2, Part 3, Part 4.

Quick Tip: Somewhere over the Rainbow

Seeing the rainbow under voltage indicator? It may not be the power supply but the cable you used to connect it to the Pi.

Have a link you would like to see included here, please email it to rpise@emaildodo.com.

[raspberrypise]

Tracking Your System’s Configuration Changes with Etckeeper

Author: Steve Robillard

Note: this post assumes a basic knowledge of git. If you are unfamiliar with git I suggest you work through one of the git tutorials available online, see the additional resources section below.

Etckeeper is a utility that allows us to version control the contents of the /etc directory, using git, mercurial, darcs, or bzr. We will use git in this post. So why would we want to version control the /etc directory?

The /etc directory is the main configuration directory on Linux (though not the only place that configuration data is kept), and DevOps best practices suggest tracking configuration changes like you would your source code. Also, when something breaks the most likely cause is the most recent change. With version control we can see exactly what was changed, when and by whom (including changes made by apt).

Similarly, how many times have you wished, after hours of working to get something working, that you could return the system to a known good state, and start fresh? For example, look at the number of networking questions that resulted from users following older tutorials to setup a static IP, after the Pi Foundation introduced a new non-standard network configuration in May of 2015. With version control we could have made and tested these changes in isolation, and if necessary discard or roll them back, returning the system to a known good state.

Installation

Update and upgrade the system:

sudo apt-get update && sudo apt-get upgrade

Install git:

sudo apt-get install git

Configure git for the root account:

sudo git config --global user.name "Your Name" sudo git config --global user.email youremailaddress

Configure git for your normal account. While not necessary for etckeeper this ensures that it is configured when you use git for your personal projects, you do version control your code don’t you? You need to switch to your home directory before doing this, and switch back to /etc after.

git config --global user.name "Your Name" git config --global user.email youremailaddress

Install etckeeper:

Sudo apt-get install etckeeper

Because git is already installed this will not only install etckeeper, but initialize the database and make an initial commit of the files in /etc.

You can check the status of the repository with the following commands:

cd /etc sudo git status

you should see the following:

On branch master nothing to commit, working directory clean

Note: if you run a git command in /etc without sudo you will see an error message like the following:

fatal: Not a git repository (or any of the parent directories): .git

There are a couple of configuration changes I suggest you make.

Open the config file with nano:

sudo nano /etckeeper/etckeeper.conf

locate the following line:

#AVOID_DAILY_AUTOCOMMITS=1

And change it to (uncomment – remove the #):

AVOID_DAILY_AUTOCOMMITS=1

This will prevent code from being automatically committed once a day. I feel that all changes should be explicit and include appropriate commit messages. Something that is not possible with auto commits. Changes made by apt will be automatically committed, but you explicitly asked it to run and hence commit.

Locate the following line:

#AVOID_COMMIT_BEFORE_INSTALL=1

And change it to:

AVOID_COMMIT_BEFORE_INSTALL=1

This will prevent the system automatically committing before an apt-get install. My reasoning is largely the same as above. If you have uncommitted changes when running apt-get install the install will fail, and you will need to commit the changes before rerunning apt.

Save the changes:

ctrl-o and enter

Then exit the editor:

ctrl-x

If you now check the status of the repository you will see that the etckeeper.conf file has been modified. We now need to stage it and commit the file to the repository. Because this is not a new file we can do this in one step with the following command:

sudo git commit –am “disable auto commits”

To further protect this data we can push it to a remote repository like github or bitbucket. Both offer free accounts but github charges for private repositories. For security reasons this repository should not be publicly accessible. Creating an account and new repository on these services is outside the scope of this article, but once you have done this you can add the remote repository and push changes to your remote repository.

Note: you will need to create an SSH key for the root user, and add it to your github or Bitbucket account for the following to work, both of the above services have documentation explaining how to do this.

Start by switching to the /etc directory:

cd /etc

add the remote repository:

sudo git remote add origin yourrepository’sURL

push all the changes to the remote repository:

sudo git push -u origin master

check the status to confirm it worked:

sudo git status

You should see something like the following:

On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean

Etckeeper can be configured to automatically push changes to the remote repository, however, I don’t suggest you do this, since it will still require you entering the passphrase for your SSH key, or adding it to the SSH agent. You did protect your SSH key with a passphrase didn’t you?

Remember etckeeper is only a wrapper around git, so all of the standard git tools and commands are available, branching, logs, stash, diff etc.

You now have a safer environment to modify and configure your system, and the knowledge that you can always return your system to a kn own good state. Additionally in the event of SD card corruption a simple git pull can recover all of the configuration changes you made to your system's etc. directorty.

Additional Resources

Codecademy's Git Course

Bitbucket

Github

Git succinctly

Pro Git

[raspberrypise]

Quick Links

This is the first in a series of semi-regular recurring posts, where we will share interesting Pi related hardware, projects and tips. 

Full page OS Is a Raspberry Pi distro designed to show one webpage in full screen mode. 

Razzmaster is a nodeJS app to help identify Pi’s on your network, configure the network and install packages. if you have multiple Pis it can even flash the LED to help identify the correct one. 

Quick Tip: Apt, just Apt

In current versions of Raspbian and Ubuntu you can replace apt-get with apt. Besides being a few characters shorter it comes with colored output and a nice progress bar. 

Have a link you would like to see included here, please email it to rpise@emaildodo.com.

[raspberrypise]

An Introduction to Crontab

Author: Jacobm001

What is Crontab?

According to its manpage, crontab is the program used to install, deinstall, or list the tables used to drive the cron daemon. In plain English, crontab is the tool used to schedule applications to be run via the cron daemon.

What should I use it for?

You can use a crontab entry anytime you have a task that needs to be run in a routine manner. Sometimes that's a script that runs at a specific time interval, a recurring entry, or when the Raspberry Pi's state changes. Examples could include things like running a command every time the Raspberry Pi starts, or reading a sensor every 5 minutes.

Another advantage of contrab is the command issues will be run regardless of whether you're logged in or not. That means you don't need to worry about turning your tiny program into a full fledged daemon, or running an additional program like screen or tmux in the background.

Using Crontab

You can open your crontab by using the command crontab -e. If you've never opened it, you'll be prompted for a favorite text editor. Personally, I'd recommend nano for this task. Once chosen (if it hadn't been already), you'll see something like:

# Edit this file to introduce tasks to be run by cron. # # Each task to run has to be defined through a single line # indicating with different fields when the task will be run # and what command to run for the task # # To define the time you can provide concrete values for # minute (m), hour (h), day of month (dom), month (mon), # and day of week (dow) or use '*' in these fields (for 'any').# # Notice that tasks will be started based on the cron's system # daemon's notion of time and timezones. # # Output of the crontab jobs (including errors) is sent through # email to the user the crontab file belongs to (unless redirected). # # For example, you can run a backup of all your user accounts # at 5 a.m every week with: # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/ # # For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command

Like most Unix configuration files, # indicates that the following line is a comment. That makes the beginning of this file unnecessary, but I highly recommend you keep it around as a reference. It's much more convenient than constantly going back and forth from the man pages.

As you can see in this example, you can issue a complete command (like tar) or you can reference a file. Personally, most of my tasks tend to be on the longer side. That makes them difficult to manage in the crontab. Instead, I store them in a hidden directory in my user's home directory named /home/pi/.cron_scripts.

An Example

For this example we're going to archive my website's directory and then push it to a remote location.

Step 1: Create a new script

Here, we'll write the little program that handles the archiving and pushing of our files. Create a new script by running nano ~/.cron_scripts/backup.sh. Into that file put:

#!/bin/usr/sh tar cfa ~/backup.tar.xz /var/www/html scp ~/backup.tar.xz user@host.com:/backups/backup.tar.xz rm ~/backup.tar.xz

Exit nano (Ctrl-o Ctrl-x) and then make it executable with the command chmod +x ~/.cron_scripts/backup.sh.

Step 2: Test the script

It may sound silly to test such a simple script, but trust me, troubleshooting here is far easier than at any other step in this process. If you script doesn't work here, it's going to be much more difficult to find out while something is going wonky later. Run the script with ~/.cron_scripts/backup.sh. Once it's done, check and make sure your directory made it where it was supposed to go.

Step 3: Add your script to Cron

At this point, you need to choose how often you want to backup your website. For this case, I'll pick a truly arbitrary number and go with weekly backups on Tuesdays at 6:31 in the evening. That gives us an h value of 18 (24 hour format), an m value of 31, and a dow value of 3. Everything else is a *. That gives us the line:

31 18 * * 3 /home/pi/.cron_scripts/backup.sh

Notice that I did not use home directory shortcut, ~. When using crontab, it's best to always use full paths, rather than relative.

Other Useful Crontab Commands

There are some commands that can be used in place of the standard time format. @reboot will run the command any time the Raspberry Pi is restarted, and there's a shortcut for @hourly, @daily, @weekly, @monthly, @annually, and @yearly.

The last thing I'll mention is that you can setup multiple values for any portion of the time entry. So if you wanted something to run at 1 in the morning and 1 in the evening, you can set the h value to 1/13. Make sure there isn't a space or it'll throw the whole thing off!

As always, there's more to his tool than what can be covered here. Play with cron, and spend some time looking at the man page. You never know what useful things you might find in the manual!

[raspberrypise]

Improving the Usability of the Nano Editor

Author: Steve Robillard

Every Linux user will have their favorite editor (please no holy wars about the best editor – it is a personal choice); mine is Nano. It may not be as powerful as Emacs or Vim, but it also doesn’t require remembering arcane keyboard shortcuts, or come with a Mount Everest learning curve either. I have used both Emacs and Vim, but Nano is still my editor of choice – partially because it is very similar to the Vax editor (EDT) I used in university.

The default installation leaves a lot of room for improvement. By default it doesn’t show line numbers or cursor position, jumps when scrolling through a file, making it hard to scan the text, and lacks syntax highlighting. We can solve all of these problems with a ~/.nanorc file.

Note you can copy and rename the system wide config file (/etc/nanorc) to your home directory and edit or uncomment the features you want to enable, but I prefer creating the file from scratch with only the changes I need reducing the noise and clutter.

To begin switch to your home directory

cd

create an empty .nanorc file:

touch .nanorc

then open it with nano

nano .nanorc

To enable line numbers and cursor position add the following:

### Enable line numbers set const

Lines that begin with # (e.g. ### Enable line numbers are comments) and are ignored by nano. But they can help when trying to remember that set const is for line numbering - which is not exactly the clearest or most semantic choice.

To enable line by line scrolling instead of the chunk by chunk default behavior, add:

### Enable smooth scrolling set smooth

Nano comes with several language specific syntax files (e.g python, php, html etc.). By default these are installed in the /usr/share/nano directory. You can link to these files from your .nanorc file by including the following:

### Enable syntax highlighting for .sh files include /usr/share/nano/sh.nanorc

However, there are a few drawbacks to this approach. First they are global shared files; which means that any change you make (e.g. changing the color of keywords) will affect all users who have linked to this file. You may love pink highlighted keywords, but others may not share your avant-garde color choices. This may not be that big a deal on the Pi – where multiple user setups are less common, but should be avoided. Second, on other systems where you do not have admin privileges you may not be able to edit these files. Lastly, the default files provide no support for several common languages (e.g. javascript, lua, puppet).

A better approach would be to maintain your own copy of the nano syntax highlighting files. Thankfully github user scopatz https://github.com/scopatz/nanorc has made this as easy as cloning a repository and including the files in your .nanorc file. First we will need to install git:

sudo apt-get update sudo apt-get install git

Switch to your home directory:

cd

Clone the repository:

git clone https://github.com/scopatz/nanorc.git ~/.nano

if you included:

### Enable syntax highlighting include /usr/share/nano/sh.nanorc

From above, change it to:

### Enable syntax highlighting

Save the file:

Ctrl-O and Enter

And exit nano:

Ctrl-x

To Include the syntax highlighting files enter the following at the command propmpt:

find ~/.nano/ -iname "*.nanorc" -exec echo include {} \; >> ~/.nanorc

This will append an include line for each syntax file in your .nano directory.

The complete file will now contain the following:

### Enable line numbers set const ### Enable smooth scrolling set smooth ###### Enable syntax highlighting include /home/pi/.nano/yum.nanorc include /home/pi/.nano/pkgbuild.nanorc include /home/pi/.nano/json.nanorc include /home/pi/.nano/keymap.nanorc include /home/pi/.nano/xresources.nanorc include /home/pi/.nano/makefile.nanorc include /home/pi/.nano/erb.nanorc include /home/pi/.nano/markdown.nanorc include /home/pi/.nano/pov.nanorc include /home/pi/.nano/Dockerfile.nanorc include /home/pi/.nano/zshrc.nanorc include /home/pi/.nano/yaml.nanorc include /home/pi/.nano/cmake.nanorc include /home/pi/.nano/ledger.nanorc include /home/pi/.nano/vi.nanorc include /home/pi/.nano/po.nanorc include /home/pi/.nano/javascript.nanorc include /home/pi/.nano/sed.nanorc include /home/pi/.nano/nginx.nanorc include /home/pi/.nano/privoxy.nanorc include /home/pi/.nano/rpmspec.nanorc include /home/pi/.nano/git.nanorc include /home/pi/.nano/mutt.nanorc include /home/pi/.nano/email.nanorc include /home/pi/.nano/gitcommit.nanorc include /home/pi/.nano/ocaml.nanorc include /home/pi/.nano/dot.nanorc include /home/pi/.nano/coffeescript.nanorc include /home/pi/.nano/rust.nanorc include /home/pi/.nano/lua.nanorc include /home/pi/.nano/conky.nanorc include /home/pi/.nano/html.nanorc include /home/pi/.nano/vala.nanorc include /home/pi/.nano/php.nanorc include /home/pi/.nano/man.nanorc include /home/pi/.nano/css.nanorc include /home/pi/.nano/csharp.nanorc include /home/pi/.nano/peg.nanorc include /home/pi/.nano/inputrc.nanorc include /home/pi/.nano/js.nanorc include /home/pi/.nano/gentoo.nanorc include /home/pi/.nano/mpdconf.nanorc include /home/pi/.nano/puppet.nanorc include /home/pi/.nano/sls.nanorc include /home/pi/.nano/fish.nanorc include /home/pi/.nano/tex.nanorc include /home/pi/.nano/nanorc.nanorc include /home/pi/.nano/zsh.nanorc include /home/pi/.nano/ini.nanorc include /home/pi/.nano/python.nanorc include /home/pi/.nano/haml.nanorc include /home/pi/.nano/systemd.nanorc include /home/pi/.nano/glsl.nanorc include /home/pi/.nano/lisp.nanorc include /home/pi/.nano/awk.nanorc include /home/pi/.nano/swift.nanorc include /home/pi/.nano/cython.nanorc include /home/pi/.nano/tcl.nanorc include /home/pi/.nano/groff.nanorc include /home/pi/.nano/java.nanorc include /home/pi/.nano/patch.nanorc include /home/pi/.nano/perl.nanorc include /home/pi/.nano/xml.nanorc include /home/pi/.nano/scala.nanorc include /home/pi/.nano/pkg-config.nanorc include /home/pi/.nano/sql.nanorc include /home/pi/.nano/arduino.nanorc include /home/pi/.nano/perl6.nanorc include /home/pi/.nano/kickstart.nanorc include /home/pi/.nano/sh.nanorc include /home/pi/.nano/go.nanorc include /home/pi/.nano/ruby.nanorc include /home/pi/.nano/c.nanorc include /home/pi/.nano/fortran.nanorc include /home/pi/.nano/apacheconf.nanorc include /home/pi/.nano/haskell.nanorc include /home/pi/.nano/asciidoc.nanorc include /home/pi/.nano/conf.nanorc include /home/pi/.nano/colortest.nanorc include /home/pi/.nano/asm.nanorc include /home/pi/.nano/reST.nanorc

To test your changes reopen the .nanorc file:

nano .nanorrc

You should now have line numbers and cursor position indicated above the menu at the bottom of the screen and nicely highlighted code. If you arrow down through the file it should scroll one line at a time.

I have only touched the surface of the customizations nano supports. You can view the full list of options with the man command:

man nanorc

If Python is your primary language you may want to look at the following options tabsize, tabstospaces and autoindent. If you are a mouse centric user you may want to enable the mouse option.

Additional Resources

Nano Tips and tricks https://www.if-not-true-then-false.com/2009/tuning-nano-text-editor-with-nanorc/

A two part series on nano shortcuts and syntax highlighting part 1 and part 2

[raspberrypise]

A Blog Update and Our Giveaway

Author Jacobm001

Why no post last week?

As you may have noticed, we didn't have a post last week. Unfortunately, I have been extremely busy with my final term as a college student. I have officially graduated (yay me!) and we will now be going back to our regularly scheduled posts starting next week.

The Giveaway

As mentioned previously, we're giving away a Raspberry Pi to one of our community contributers. We've narrowed down the sellection to PM for his article on the RPi's power rails and the the Brown One's article on setting up a LAMP stack.

If you haven't voted yet, GO VOTE for your favorite. Voting will close at 23:59 (UTC) on Monday the 20th.

[raspberrypise]

Making Bash History More Useful

Author: Steve Robillard

One of the most useful command line features is the Bash history. Commands you enter at the command line are stored in a file called ~/.bash_history. To view the contents of your Bash history use the following command:

History.

The first column is the history number and the second is the command.

320 startx 321 ping 192.168.1.243 322 df 323 du 324 df -h 325 ssh pi@alfa.local

To rerun one of the commands type a bang(!) and the command number. To rerun the ping command use the following:

!321.

You can also rerun past commands by using the up and down arrow to scroll through past commands. To rerun the ping command hit the up arrow once and then hit enter.

By default Raspbian limits the history file to 1000 commands and 2000 lines. However, more than once I needed to rerun a command and it was no longer in my history. With a few changes we can increase these limits or even remove them.

These limits are controlled by the HISTSIZE and HISTFILESIZE variables and are set in your ~/.bashrc file. The HISTSIZE variable controls the number of commands to remember. Setting this to 0 will prevent commands from being stored in history. Setting this to a number less than 0 will save every command (unlimited). Setting this to any other number will allow storing up to that number of commands.

The HISTFILESIZE variable sets the maximum number of lines the file can contain. It will remove older entries to prevent the number of lines exceeding this value. Similar to HISTSIZE, a 0 value will truncate the file to zero lines (no history). Negative values disable truncation, and all other numbers truncate the file to the specified number of lines.

So we could set both HISTSIZE and HISTFILESIZE to -1 and have unlimited history. But as the old adage goes there is no such thing as a free lunch. As the file grows it consumes more resources. On a memory and CPU constrained system like the Pi this could become an issue. So instead let’s start by increasing the limits to 10,000 commands and 20,000 lines. To change these limits open your ~/.bashrc file:

cd nano .bashrc

locate the following lines:

HISTSIZE=1000 HISTFILESIZE=2000,

and change them to:

HISTSIZE=10000 HISTFILESIZE=20000.

Save the file ctrl-o and exit ctrl-x the editor. Reload the ~./bashrc file source ~/.bashrc to update the values.

This is better but only delays the length of time before we begin losing older commands from history. To prevent this and avoid the performance hit of setting an unlimited history size, we can keep a full list of commands in a file that is not loaded automatically when Bash starts. To do this we can add the following to our .bashrc file.

cd nano .bashrc

copy and paste the following to the bottom of the file:

# Bash eternal history # -------------------- # This snippet allows infinite recording of every command you've ever # entered on the machine, without using a large HISTFILESIZE variable, # and keeps track if you have multiple screens and ssh sessions into the # same machine. It is adapted from: # http://www.debian-administration.org/articles/543. # # The way it works is that after each command is executed and # before a prompt is displayed, a line with the last command (and # some metadata) is appended to ~/.bash_eternal_history. # # This file is a tab-delimited, timestamped file, with the following # columns: # # 1) user # 2) hostname # 3) screen window (in case you are using GNU screen) # 4) date/time # 5) current working directory (to see where a command was executed) # 6) the last command you executed # # The only minor bug: if you include a literal newline or tab (e.g. with # awk -F"\t"), then that will be included verbatime. It is possible to # define a bash function which escapes the string before writing it; if you # have a fix for that which doesn't slow the command down, please submit # a patch or pull request. PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo -e $$\\t$USER\\t$HOSTNAME\\tscreen $WINDOW\\t`date +%D%t%T%t%Y%t%s`\\t$PWD"$(history 1)" >> ~/.bash_eternal_history' # Turn on checkwinsize shopt -s checkwinsize #Prompt edited from default [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u \w]\\$ " if [ "x$SHLVL" != "x1" ]; then # We're not a login shell for i in /etc/profile.d/*.sh; do if [ -r "$i" ]; then . $i fi done fi fi # Append to history # See: http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/x329.html shopt -s histappend

Save the file ctrl-o and exit ctrl-x the editor. Reload the ~./bashrc file to reload the new configuration.

This will save commands to a file (~/.bash_eternal_history). You can test the changes by entering a few commands:

ls –la ping 8.8.8.8 cd /etc ls –la cd

Now check the contents of the new file with the following command:

cat ~/.bash_eternal_history

You should see something like the following:

2780 pi Jaguar screen 05/31/16 17:40:17 2016 1464730817 /home/pi 2053 ls -la 2780 pi Jaguar screen 05/31/16 17:40:25 2016 1464730825 /home/pi 2054 ping 8.8.8.8 2780 pi Jaguar screen 05/31/16 17:40:30 2016 1464730830 /etc 2055 cd /etc/ 2780 pi Jaguar screen 05/31/16 17:40:33 2016 1464730833 /etc 2056 ls -la 2780 pi Jaguar screen 05/31/16 17:40:35 2016 1464730835 /home/pi 2057 cd

If you implemented the system for managing your .bashrc file I described in part 4 of my Improving Your Command Line Skills Series, you can simply create a new file (e.g. bash_eternal_history.sh) in your .bashrc.d directory with the code from above, and reload the .bashrc file.

Below are several useful commands for working with this new file:

tail ~/.bash_eternal_history # list the last 10 lines of the file grep ~/.bash_eternal_history “jira” # list all lines include “jira” wc –l .bash_eternal_history # count the number of lines in the file.

Next time you need to remove a PID file to restart a program, or restart a program that doesn’t use the standard service command you’ll be able to find and rerun the necessary command.

Additional Resources

How to use Bash History Commands and Expansions

The Definitive Guide to Bash Command Line History

Understanding Bash History