Mosquitto on Raspberry Pi 4

mqttI currently have The Eclipse Mosquitto MQTT broker running on the Raspberry Pi 2, 3 and 4, including Stretch and Buster Raspbian, not to mention countless other variations of Debian and Ubuntu on various boards used at one time or another (Orange Pi, various FriendlyArm boards and far more).

Below is the link I originally followed for the install – Mosquitto is now part of my standard install using “the script” – today (July 2019). See my Bitbucket area and other parts of this blog for more on “the script”. I still use the Mosquitto broker having looked at several alternatives – I keep looking at the MOSCA Nod-Red broker – but it doesn’t seem to be going anywhere – i.e. not ready for production apparently (that message has been on the relevant GIT repository for a long time) – well, Mosquitto IS ready and it is also free and easy to use – I use it 24-7 in my own installations here in Spain and back in my home in the UK (still currently on RPI3 on the latter), not to mention countless installations I’ve helped put together for others. I started running Mosquitto on RPI2, then RPI3 and now RPI4.

The rest of this blog entry was constructed as far back as 2015…

http://jpmens.net/2013/09/01/installing-mosquitto-on-a-raspberry-pi/

I simply installed the repository then Mosquitto itself, nothing more.

This installation put a non-personalised config file at /etc/mosquitto – so in there was pointed to the directory /etc/mosquitto/conf.d  – so I put my mosquitto.conf in there which was basically 2 lines…

allow_anonymous false
password_file /etc/mosquitto/conf.d/passwords.txt

I’ve not yet put SSL in there but I certainly wasn’t going to start up the broker with NO security.  I added a simple text file passwords.txt as above with a one-liner admin (colon) password where the password is encrypted using the Mosquitto password program for the PC (thankfully I already had a passwords file).

And that’s it really, stop the broker and restart it to make sure it takes notice of the config file..

sudo /etc/init.d/mosquitto stop

sudo /etc/init.d/mosquitto start

And talk to it via something like MQTT SPY – subscribe to any old topic (“testing”, in my case) and try publishing to that topic. I’ve tested powering down and back up and all is well.

Easiest thing I’ve done all day.. oh, NO it wasn’t – I could not write to the etc/mosquitto/conf.d directory  – the usual Linux security issues….  I did this.. most likely giving FAR too much access (if anyone wants to tell me what it SHOULD be, please do but don’t let’s get complicated)…

sudo chmod 777 ./conf.d

and from there on I could use my FTP described earlier and Notepad++ to create and edit the necessary files.

Facebooktwitterpinterestlinkedin

6 thoughts on “Mosquitto on Raspberry Pi 4

  1. Giving 777 permissions is bad,it allows everyone connected to the system to create and execute files.

    Personally i would have simply edited the file as root (sudo vi /etc/mosquitto/conf.d/mosquitto.conf) (or whichever editor you want to use).

    1. Agree 777 is bad, especially if you have your password file stored there. You shouldn’t need to modify the permissions of that folder it should be set so that the mosquitto (root) demon can read and write thats about it.

      As Tomer suggested try using sudo to run a text editor like vi to edit the file with elevated permissions, although if you are starting out I would recommend nano as it is much easier to learn/use than VI. If you want to keep your current method of using WinSCP and a windows text editor then create a new user and add them to the root user group (note: this really isn’t recommended, but it is better than setting all files to RWX for all users).

      1. Why not use the user root when connecting with WinSCP. 😉

        In Raspbian user root is not active by default. But you can activate it by running command “sudo passwd root” without the quotes and type a root password twice.

        1. From a security perspective it isn’t best practice if you plan to have SSH enables to the internet as you are exposing your self to brute force attacks.

          On that note, Pete if you are planning on making ssh available from the internet I would highly recommend you install fail2ban it is in the apt-get repository and will automatically ban IP addresses after 3 failed SSH logins.

          1. Pete,

            I second what Ben is saying here. I had a similar setup for a while with my RPi being web accessible via ssh. So one day just out of curiosity I checked the /var/log/auth.log; to my surprise I found out that some douche-bag had been very busy trying to brute-force in to my home network. I suggest disabling root’s remote ssh access; and configure a key-based ssh authentication instead of a password based one while you are at it.

            Happy hacking.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.