{"id":1756,"date":"2017-04-17T06:53:50","date_gmt":"2017-04-17T13:53:50","guid":{"rendered":"http:\/\/internetofhomethings.com\/homethings\/?p=1756"},"modified":"2017-04-19T17:05:35","modified_gmt":"2017-04-20T00:05:35","slug":"vps-application-1-mqtt-broker","status":"publish","type":"post","link":"https:\/\/internetofhomethings.com\/homethings\/?p=1756","title":{"rendered":"VPS Application 1: MQTT Broker"},"content":{"rendered":"

\"\"<\/a><\/p>\n

Using an MQTT Broker to publish and subscribe to IoT events is a critical aspect of many IoT infrastructures. And hosting your own broker retains complete control in your hands. This writing provides step-by-step instructions for installing the Mosquitto MQTT broker on a VPS running Linux Ubuntu 16.04.<\/p>\n

Don’t have a personal Virtual Private Server (VPS)? Check here <\/a>\u00a0to find out how to get one.<\/p>\n

MQTT Broker Installation Overview<\/strong><\/h2>\n

Installing the Mosquitto MQTT broker on your Linux Ubuntu VPS can be broken down into 3 basic steps. And if you wish to also provide secure connections, four additional steps are needed.<\/p>\n

    \n
  1. Install Mosquitto<\/li>\n
  2. Configuring MQTT Passwords<\/li>\n
  3. Configuring MQTT Over Websockets<\/li>\n
  4. Securing your MQTT Broker\n
      \n
    1. Install Certbot<\/li>\n
    2. Run Cerbot<\/li>\n
    3. Setting up Certbot Automatic Renewals<\/li>\n
    4. Configuring MQTT SSL<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

      Installing Mosquitto<\/strong><\/h2>\n

      A \u00a0telnet client is needed to install and configure the MQTT broker on your VPS. PuTTY is a widely used telnet client. It can be downloaded here<\/a>. Make sure you have a telnet client installed and your non-root linux user credentials are handy before continuing.<\/p>\n

      Then, log in with your non-root user with PuTTY and install Mosquitto with apt-get by entering:<\/code><\/p>\n

      sudo apt-get install mosquitto mosquitto-clients<\/p>\n

      The MQTT broker service will start automatically after the installation has completed. To test, open a second command-line interface (CLI) using PuTTY. With one of the terminal windows, subscribe to a test topic named “mymqtttesttopic” by entering:<\/p>\n

      mosquitto_sub -h localhost -t mymqtttesttopic<\/p>\n

      \"\"<\/a><\/p>\n

      Then, publish a message from the other terminal:<\/p>\n

      mosquitto_pub -h localhost -t mymqtttesttopic -m “Sent from my own MQTT Broker”<\/p>\n

      \"\"<\/a><\/p>\n

      If the installation is properly working, the subscribe terminal will receive the message:<\/p>\n

      \"\"<\/a><\/p>\n

      Configuring MQTT Passwords<\/strong><\/h2>\n

      First level of security is to configure Mosquitto to use passwords. Mosquitto includes a utility to generate a special password file called mosquitto_passwd<\/code>. Using this\u00a0utility, you will be\u00a0prompted to enter a password for the specified username, and place the results in \/etc\/mosquitto\/passwd<\/code>. From the terminal, enter:<\/p>\n

      sudo mosquitto_passwd -c \/etc\/mosquitto\/passwd testuser<\/span><\/p>\n

      Note<\/strong>: Use “password” for the password for this test case when prompted<\/em><\/p>\n

      Now we’ll open up a new configuration file for Mosquitto and tell it to use this password file to require logins for all connections:<\/p>\n

      sudo nano \/etc\/mosquitto\/conf.d\/default.conf<\/p>\n

      This should open an empty file. Paste in the following:<\/p>\n

      \/etc\/mosquitto\/conf.d\/default.conf<\/div>\n
      allow_anonymous false\r\npassword_file \/etc\/mosquitto\/passwd\r\n<\/code><\/pre>\n
      allow_anonymous false<\/code> will disable all non-authenticated connections, and the password_file<\/code> line tells Mosquitto where to look for user and password information. Save and exit the file.<\/p>\n
      Now we need to restart Mosquitto and test our changes:<\/p>\n
      sudo systemctl restart mosquitto<\/p>\n
      Try to publish a message without a password:<\/p>\n
      mosquitto_pub -h localhost -t “test” -m “hello world”<\/p>\n
      The message should be rejected:<\/p>\n
      Output<\/div>\n
      Connection Refused: not authorized.\r\nError: The connection was refused.\r\n<\/code><\/pre>\n
      Before we try again with the password, switch to your second terminal window again, and subscribe to the ‘test’ topic, using the username and password this time:<\/p>\n
      mosquitto_sub -h localhost -t test -u “testuser<\/span>” -P “password<\/span>”<\/p>\n
      It should connect and sit, waiting for messages. You can leave this terminal open and connected for the rest of the tutorial, as we’ll periodically send it test messages.<\/p>\n
      Now publish a message with your other terminal, again using the username and password:<\/p>\n
      mosquitto_pub -h localhost -t “test” -m “hello world” -u “testuser<\/span>” -P “password<\/span>”<\/p>\n
      The message should be passed from one terminal to the other in the same way as the initial test without passwords. If the message was received, we have successfully added password protection to our Mosquitto MQTT Broker.<\/p>\n
      Passwords for multiple users<\/strong><\/h2>\n
      Most likely, your MQTT broker will need to support more than one user. Here is how to create a password file for multiple users:<\/p>\n
      First create a plain text file<\/strong>, adding a line for each user: <username>:<password><\/p>\n
      sudo nano \/etc\/mosquitto\/passwd<\/p>\n
      For 3 users, the file contents:<\/p>\n
      username1:password1
      \nusername2:password2
      \nusername3:password3<\/p>\n
      Then encrypt the plain text file<\/strong>\u00a0by entering:<\/p>\n
      sudo mosquitto_passwd -U \/etc\/mosquitto\/passwd<\/p>\n
      Configuring MQTT Over Websockets<\/strong><\/h2>\n
      You will probably want to have your MQTT Broker support Websockets. This makes it possible to communicate with your MQTT broker using JavaScript. Very useful for web applications. Here is how to add it to your Mosquitto configuration.<\/p>\n
      Open the configuration file to add port listeners:<\/p>\n
      sudo nano \/etc\/mosquitto\/conf.d\/default.conf<\/p>\n
      Add to the bottom of the file:<\/p>\n
      listener 1883 localhost<\/p>\n
      listener 8883<\/p>\n
      listener 8083
      \nprotocol websockets<\/p>\n
      listener 18083
      \nprotocol websockets<\/p>\n
      Then update the firewall to support these listener ports.<\/p>\n
      sudo ufw allow 8883
      \nsudo ufw allow 8083
      \nsudo ufw allow 18083<\/p>\n
      Restart Mosquitto to activate the listener configuration:<\/p>\n
      sudo systemctl restart mosquitto<\/p>\n
      Here is the MQTT port allocation:<\/p>\n
      [wptg_comparison_table id=”21″]<\/p>\n
      Note that the last listener on port 18083 is not a standard MQTT port. This port is used for insecure (non-encrypted connections). While it is not required, it can sometimes be useful when communicating with tiny IoT devices that cannot support the additional overhead required to connect using the SSL protocol.<\/p>\n
      Testing MQTT Websockets<\/strong><\/h2>\n
      The easiest method of verifying the Websockets ports is to use a web browser MQTT client. While there are many such tools available, HiveMQ will be used for this demonstration.<\/p>\n
      First, open an incognito web browser window to\u00a0this link.<\/a><\/p>\n
      Note:<\/strong> You must use an incognito<\/strong> window. A normal browser window sends extra information to track your browsing history. This extra http traffic will interfere with the MQTT websocket protocol and cause the connection to fail.<\/em><\/p>\n
      And\u00a0create a new connection:<\/p>\n
      \"\"<\/a><\/p>\n
      Once the connection is made, publish a test message:<\/p>\n
      \"\"<\/a><\/p>\n
      Securing your MQTT\u00a0Broker<\/strong><\/h2>\n
      There are four steps required to securing the MQTT Broker with SSL\/TLS.<\/p>\n
      Step 1: Install Certbot<\/strong><\/p>\n
      We must first install the official client from an Ubuntu PPA, or Personal Package Archive<\/em>. These are alternative repositories that package more recent or more obscure software. First, add the repository from the VPS terminal.<\/p>\n
      sudo add-apt-repository ppa:certbot\/certbot<\/strong><\/p>\n
      Note: If this command is not found, the following package needs to be installed first:<\/p>\n
      sudo apt-get install software-properties-common<\/code><\/strong><\/p>\n
      You’ll need to press ENTER<\/code> to accept. Afterwards, update the package list to pick up the new repository’s package information.<\/p>\n
      sudo apt-get update <\/strong><\/p>\n
      And finally, install the official Let’s Encrypt client, called certbot<\/code>.<\/p>\n
      sudo apt-get install certbot <\/strong><\/p>\n
      Now that we have certbot<\/code> installed, let’s run it to get our certificate.<\/p>\n
      Step 2: Run Certbot<\/strong><\/p>\n
      The Certbot<\/code>\u00a0that was just installed needs to answer a cryptographic challenge issued by the Let’s Encrypt API in order to prove we control our domain. It uses ports 80<\/code> (HTTP) and\/or 443<\/code> (HTTPS) to accomplish this. We’ll only use port 80<\/code>, so let’s allow incoming traffic on that port now:<\/p>\n
      sudo ufw allow http<\/strong><\/p>\n
      Output<\/div>\n
      Rule added\r\n<\/code><\/pre>\n
      We can now run Certbot to get our certificate. We’ll use the --standalone<\/code> option to tell Certbot to handle the HTTP challenge request on its own, and --standalone-supported-challenges http-01<\/code> limits the communication to port 80<\/code>. -d<\/code> is used to specify the domain you’d like a certificate for, and certonly<\/code> tells Certbot to just retrieve the certificate without doing any other configuration steps.<\/p>\n
      sudo certbot certonly –standalone –standalone-supported-challenges http-01 -d mqtt.example.com<\/span><\/strong><\/p>\n
      When running the command, you will be prompted to enter an email address and agree to the terms of service. After doing so, you should see a message telling you the process was successful and where your certificates are stored.<\/p>\n
      We’ve got our certificates. Now we need to make sure Certbot renews them automatically when they’re about to expire.<\/p>\n
      Step 3: Setting up Cerbot Automatic Renewals<\/strong><\/p>\n
      Let’s Encrypt’s certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process. We’ll need to set up a regularly run command to check for expiring certificates and renew them automatically.<\/p>\n
      To run the renewal check daily, we will use cron<\/code>, a standard system service for running periodic jobs. We tell cron<\/code> what to do by opening and editing a file called a crontab<\/code>.<\/p>\n
      sudo crontab -e <\/strong><\/p>\n
      You’ll be prompted to select a text editor. Choose your favorite, and you’ll be presented with the default crontab<\/code> which has some help text in it. Paste in the following line at the end of the file, then save and close it.<\/p>\n
      crontab<\/div>\n
      . . .\r\n15 3 * * * certbot renew --noninteractive --post-hook \"systemctl restart mosquitto\"\r\n<\/code><\/pre>\n
      The 15 3 * * *<\/code> part of this line means “run the following command at 3:15 am, every day”. The renew<\/code>command for Certbot will check all certificates installed on the system and update any that are set to expire in less than thirty days. --noninteractive<\/code> tells Certbot not to wait for user input.<\/p>\n
      --post-hook \"systemctl restart mosquitto\"<\/code> will restart Mosquitto to pick up the new certificate, but only if the certificate was renewed. This post-hook<\/code> feature is what older versions of the Let’s Encrypt client lacked, and why we installed from a PPA instead of the default Ubuntu repository. Without it, we’d have to restart Mosquitto every day, even if no certificates were actually updated. Though your MQTT clients should be configured to reconnect automatically, it’s wise to avoid interrupting them daily for no good reason.<\/p>\n
      Now that automatic certificate renewal is all set, we’ll get back to configuring Mosquitto to be more secure.<\/p>\n
      Step 4. Configuring MQTT SSL<\/strong><\/p>\n
      To enable SSL encryption, we need to tell Mosquitto where our Let’s Encrypt certificates are stored. Open up the configuration file we previously started:<\/p>\n
      sudo nano \/etc\/mosquitto\/conf.d\/default.conf<\/p>\n
      Replace the file content with the following:<\/p>\n
      allow_anonymous false\r\npassword_file \/etc\/mosquitto\/passwd\r\n\r\nlistener  1883 localhost\r\n\r\nlistener 8883\r\ncertfile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/cert.pem\r\ncafile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/chain.pem\r\nkeyfile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/privkey.pem\r\n\r\nlistener 8083\r\nprotocol websockets\r\ncertfile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/cert.pem\r\ncafile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/chain.pem\r\nkeyfile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/privkey.pem\r\n\r\nlistener 18083\r\nprotocol websockets<\/pre>\n
      <\/div>\n
      This file is the same as the last version, except the SSL certificates have been added to the SSL and websocket ports:<\/div>\n
      \n
      certfile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/cert.pem\r\ncafile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/chain.pem\r\nkeyfile \/etc\/letsencrypt\/live\/<yourVPSdomainname>\/privkey.pem<\/pre>\n<\/div>\n
      listener 8883<\/code> sets up an encrypted listener on port 8883<\/code>. This is the standard port for MQTT + SSL, often referred to as MQTTS. The next three lines, certfile<\/code>, cafile<\/code>, and keyfile<\/code>, all point Mosquitto to the appropriate Let’s Encrypt files to set up the encrypted connections.<\/p>\n
      Save and exit the file, then restart Mosquitto to update the settings:<\/p>\n
      sudo systemctl restart mosquitto <\/strong><\/p>\n
      Now we test again using mosquitto_pub<\/code>, with a few different options for SSL:<\/p>\n
      mosquitto_pub -h <your VPS domainname><\/span>\u00a0-t test -m “hello again” -p 8883 –capath \/etc\/ssl\/certs\/ -u “user1<\/span>” -P “password<\/span>”<\/p>\n
      Note that we’re using the full hostname instead of localhost<\/code>. Because our SSL certificate is issued for <yourVPSdomainname><\/span><\/code>, if we attempt a secure connection to localhost<\/code> we’ll get an error saying the hostname does not match the certificate hostname (even though they both point to the same Mosquitto server).<\/p>\n
      --capath \/etc\/ssl\/certs\/<\/code> enables SSL for mosquitto_pub<\/code>, and tells it where to look for root certificates. These are typically installed by your operating system, so the path is different for Mac OS, Windows, etc. mosquitto_pub<\/code> uses the root certificate to verify that the Mosquitto server’s certificate was properly signed by the Let’s Encrypt certificate authority. It’s important to note that mosquitto_pub<\/code> and mosquitto_sub<\/code> will not attempt an SSL connection without this option (or the similar --cafile<\/code> option), even if you’re connecting to the standard secure port of 8883<\/code>.<\/p>\n
      If all goes well with the test, we’ll see hello again<\/strong> show up in the other mosquitto_sub<\/code> terminal.<\/p>\n
      You can also run additional tests using the HiveMQ MQTT client again to verify the websocket port 8083, which is now configured securely. This time, make sure the “SSL” checkbox is selected when making a connection.<\/p>\n
      Once this final test has been performed successfully, your MQTT broker is fully set up!<\/p>\n
      In Closing<\/strong><\/h2>\n
      With your own secure MQTT broker running on a VPS, you have a powerful platform at your disposal. Using a reliable provider, you no longer need to keep any hardware running 24-7, no longer vulnerable to power interruptions or computer crashes. And there are no constraints on your custom configuration options. That is all taken care of by the VPS provider.<\/p>\n
      I hope you find this information useful<\/p>\n","protected":false},"excerpt":{"rendered":"
      Using an MQTT Broker to publish and subscribe to IoT events is a critical aspect of many IoT infrastructures. And hosting your own broker retains complete control in your hands. …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,19,111],"tags":[88,153],"class_list":["post-1756","post","type-post","status-publish","format-standard","hentry","category-alltheposts","category-internet-of-things","category-mqtt","tag-mqtt","tag-vps-mqtt-installation"],"_links":{"self":[{"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=\/wp\/v2\/posts\/1756","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1756"}],"version-history":[{"count":27,"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=\/wp\/v2\/posts\/1756\/revisions"}],"predecessor-version":[{"id":1824,"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=\/wp\/v2\/posts\/1756\/revisions\/1824"}],"wp:attachment":[{"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1756"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1756"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/internetofhomethings.com\/homethings\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1756"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}