One place for hosting & domains

      Install

      How to Install and Configure VNC on Debian 10


      Introduction

      Virtual Network Computing, or VNC, is a connection system that allows you to use your keyboard and mouse to interact with a graphical desktop environment on a remote server. It makes managing files, software, and settings on a remote server easier for users who are not yet comfortable with the command line.

      In this guide, you’ll set up a VNC server on a Debian 10 server and connect to it securely through an SSH tunnel. You’ll use TightVNC, a fast and lightweight remote control package. This choice will ensure that our VNC connection will be smooth and stable even on slower internet connections.

      Prerequisites

      To complete this tutorial, you’ll need:

      • One Debian 10 server set up by following the Debian 10 initial server setup guide, including a non-root user with sudo access and a firewall.
      • A local computer with a VNC client installed that supports VNC connections over SSH tunnels.
        • On Windows, you can use TightVNC, RealVNC, or UltraVNC.
        • On macOS, you can use the built-in Screen Sharing program, or can use a cross-platform app like RealVNC.
        • On Linux, you can choose from many options, including vinagre, krdc, RealVNC, or TightVNC.

      Step 1 — Installing the Desktop Environment and VNC Server

      By default, a Debian 10 server does not come with a graphical desktop environment or a VNC server installed, so we’ll begin by installing those. Specifically, we will install packages for the latest Xfce desktop environment and the TightVNC package available in the official Debian repository.

      On your server, update your list of packages:

      Now install the Xfce desktop environment on your server:

      • sudo apt install xfce4 xfce4-goodies

      During the installation, you’ll be prompted to select your keyboard layout from a list of possible options. Choose the one that’s appropriate for your language and press Enter. The installation will continue.

      Once the installation completes, install the TightVNC server:

      • sudo apt install tightvncserver

      To complete the VNC server’s initial configuration after installation, use the vncserver command to set up a secure password and create the initial configuration files:

      You’ll be prompted to enter and verify a password to access your machine remotely:

      Output

      You will require a password to access your desktops. Password: Verify:

      The password must be between six and eight characters long. Passwords more than 8 characters will be truncated automatically.

      Once you verify the password, you’ll have the option to create a a view-only password. Users who log in with the view-only password will not be able to control the VNC instance with their mouse or keyboard. This is a helpful option if you want to demonstrate something to other people using your VNC server, but this isn’t required.

      The process then creates the necessary default configuration files and connection information for the server:

      Output

      Would you like to enter a view-only password (y/n)? n xauth: file /home/sammy/.Xauthority does not exist New 'X' desktop is your_hostname:1 Creating default startup script /home/sammy/.vnc/xstartup Starting applications specified in /home/sammy/.vnc/xstartup Log file is /home/sammy/.vnc/your_hostname:1.log

      Now let’s configure the VNC server.

      Step 2 — Configuring the VNC Server

      The VNC server needs to know which commands to execute when it starts up. Specifically, VNC needs to know which graphical desktop it should connect to.

      These commands are located in a configuration file called xstartup in the .vnc folder under your home directory. The startup script was created when you ran the vncserver command in the previous step, but we’ll create our own to launch the Xfce desktop.

      When VNC is first set up, it launches a default server instance on port 5901. This port is called a display port, and is referred to by VNC as :1. VNC can launch multiple instances on other display ports, like :2, :3, and so on.

      Because we are going to be changing how the VNC server is configured, first stop the VNC server instance that is running on port 5901 with the following command:

      The output should look like this, although you’ll see a different PID:

      Output

      Killing Xtightvnc process ID 17648

      Before you modify the xstartup file, back up the original:

      • mv ~/.vnc/xstartup ~/.vnc/xstartup.bak

      Now create a new xstartup file and open it in your text editor:

      Commands in this file are executed automatically whenever you start or restart the VNC server. We need VNC to start our desktop environment if it’s not already started. Add these commands to the file:

      ~/.vnc/xstartup

      #!/bin/bash
      xrdb $HOME/.Xresources
      startxfce4 &
      

      The first command in the file, xrdb $HOME/.Xresources, tells VNC’s GUI framework to read the user’s .Xresources file. .Xresources is where a user can make changes to certain settings for the graphical desktop, like terminal colors, cursor themes, and font rendering. The second command tells the server to launch Xfce, which is where you will find all of the graphical software that you need to comfortably manage your server.

      To ensure that the VNC server will be able to use this new startup file properly, we’ll need to make it executable.

      • sudo chmod +x ~/.vnc/xstartup

      Now, restart the VNC server.

      You’ll see output similar to this:

      Output

      New 'X' desktop is your_hostname:1 Starting applications specified in /home/sammy/.vnc/xstartup Log file is /home/sammy/.vnc/your_hostname:1.log

      With the configuration in place, let’s connect to the server from our local machine.

      Step 3 — Connecting the VNC Desktop Securely

      VNC itself doesn’t use secure protocols when connecting. We’ll use an SSH tunnel to connect securely to our server, and then tell our VNC client to use that tunnel rather than making a direct connection.

      Create an SSH connection on your local computer that securely forwards to the localhost connection for VNC. You can do this via the terminal on Linux or macOS with the following command:

      • ssh -L 5901:127.0.0.1:5901 -C -N -l sammy your_server_ip

      The -L switch specifies the port bindings. In this case we’re binding port 5901 of the remote connection to port 5901 on your local machine. The -C switch enables compression, while the -N switch tells ssh that we don’t want to execute a remote command. The -l switch specifies the remote login name.

      Remember to replace sammy and your_server_ip with your non-root username and the IP address of your server.

      If you are using a graphical SSH client, like PuTTY, use your_server_ip as the connection IP, and set localhost:5901 as a new forwarded port in the program’s SSH tunnel settings.

      Once the tunnel is running, use a VNC client to connect to localhost:5901. You’ll be prompted to authenticate using the password you set in Step 1.

      Once you are connected, you’ll see the default Xfce desktop.

      VNC connection to Debian 10 server

      Select Use default config to configure your desktop quickly.

      You can access files in your home directory with the file manager or from the command line, as seen here:

      Files via VNC connection to Debian 10

      On your local machine, press CTRL+C in your terminal to stop the SSH tunnel and return to your prompt. This will disconnect your VNC session as well.

      Next let’s set up the VNC server as a service.

      Step 4 — Running VNC as a System Service

      Next, we’ll set up the VNC server as a systemd service so we can start, stop, and restart it as needed, like any other service. This will also ensure that VNC starts up when your server reboots.

      First, create a new unit file called /etc/systemd/system/vncserver@.service using your favorite text editor:

      • sudo nano /etc/systemd/system/vncserver@.service

      The @ symbol at the end of the name will let us pass in an argument we can use in the service configuration. We’ll use this to specify the VNC display port we want to use when we manage the service.

      Add the following lines to the file. Be sure to change the value of User, Group, WorkingDirectory, and the username in the value of PIDFILE to match your username:

      /etc/systemd/system/vncserver@.service

      [Unit]
      Description=Start TightVNC server at startup
      After=syslog.target network.target
      
      [Service]
      Type=forking
      User=sammy
      Group=sammy
      WorkingDirectory=/home/sammy
      
      PIDFile=/home/sammy/.vnc/%H:%i.pid
      ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
      ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
      ExecStop=/usr/bin/vncserver -kill :%i
      
      [Install]
      WantedBy=multi-user.target
      

      The ExecStartPre command stops VNC if it’s already running. The ExecStart command starts VNC and sets the color depth to 24-bit color with a resolution of 1280x800. You can modify these startup options as well to meet your needs.

      Save and close the file.

      Next, make the system aware of the new unit file.

      • sudo systemctl daemon-reload

      Enable the unit file.

      • sudo systemctl enable vncserver@1.service

      The 1 following the @ sign signifies which display number the service should appear over, in this case the default :1 as was discussed in Step 2..

      Stop the current instance of the VNC server if it’s still running.

      Then start it as you would start any other systemd service.

      • sudo systemctl start vncserver@1

      You can verify that it started with this command:

      • sudo systemctl status vncserver@1

      If it started correctly, the output should look like this:

      Output

      ● vncserver@1.service - Start TightVNC server at startup Loaded: loaded (/etc/systemd/system/vncserver@.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-10-10 17:56:17 UTC; 5s ago Process: 935 ExecStartPre=/usr/bin/vncserver -kill :1 > /dev/null 2>&1 (code=exited, status=2) Process: 940 ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :1 (code=exited, status=0/SUCCESS) Main PID: 948 (Xtightvnc) . . .

      Your VNC server will now be available when you reboot the machine.

      Start your SSH tunnel again:

      • ssh -L 5901:127.0.0.1:5901 -C -N -l sammy your_server_ip

      Then make a new connection using your VNC client software to localhost:5901 to connect to your machine.

      Conclusion

      You now have a secured VNC server up and running on your Debian 10 server. Now you’ll be able to manage your files, software, and settings with an easy-to-use and familiar graphical interface, and you’ll be able to run graphical software like web browsers remotely.



      Source link

      How to Install and Secure the Mosquitto MQTT Messaging Broker on Debian 10


      Introduction

      MQTT is a machine-to-machine messaging protocol, designed to provide lightweight publish/subscribe communication to “Internet of Things” devices. It is commonly used for geo-tracking fleets of vehicles, home automation, environmental sensor networks, and utility-scale data collection.

      Mosquitto is a popular MQTT server (or broker, in MQTT parlance) that has great community support and is easy to install and configure.

      In this tutorial, we’ll install Mosquitto and set up our broker to use SSL to secure our password-protected MQTT communications.

      Prerequisites

      Before starting this tutorial, you will need:

      Step 1 — Installing Mosquitto

      Debian 10 has a fairly recent version of Mosquitto in its default software repository, so we can install it from there.

      First, log in using your non-root user and update the package lists using apt update:

      Now, install Mosquitto using apt install:

      • sudo apt install mosquitto mosquitto-clients

      By default, Debian will start the Mosquitto service after install. Let’s test the default configuration. We’ll use one of the Mosquitto clients we just installed to subscribe to a topic on our broker.

      Topics are labels that you publish messages to and subscribe to. They are arranged as a hierarchy, so you could have sensors/outside/temp and sensors/outside/humidity, for example. How you arrange topics is up to you and your needs. Throughout this tutorial we will use a simple test topic to test our configuration changes.

      Log in to your server a second time, so you have two terminals side-by-side. In the new terminal, use mosquitto_sub to subscribe to the test topic:

      • mosquitto_sub -h localhost -t test

      -h is used to specify the hostname of the MQTT server, and -t is the topic name. You’ll see no output after hitting ENTER because mosquitto_sub is waiting for messages to arrive. Switch back to your other terminal and publish a message:

      • mosquitto_pub -h localhost -t test -m "hello world"

      The options for mosquitto_pub are the same as mosquitto_sub, though this time we use the additional -m option to specify our message. Hit ENTER, and you should see hello world pop up in the other terminal. You’ve sent your first MQTT message!

      Enter CTRL+C in the second terminal to exit out of mosquitto_sub, but keep the connection to the server open. We’ll use it again for another test in Step 5.

      Next, we’ll secure our installation using password-based authentication.

      Step 2 — Configuring MQTT Passwords

      Let’s configure Mosquitto to use passwords. Mosquitto includes a utility to generate a special password file called mosquitto_passwd. This command will prompt you to enter a password for the specified username, and place the results in /etc/mosquitto/passwd.

      • sudo mosquitto_passwd -c /etc/mosquitto/passwd sammy

      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:

      • sudo nano /etc/mosquitto/conf.d/default.conf

      This should open an empty file. Paste in the following:

      /etc/mosquitto/conf.d/default.conf

      allow_anonymous false
      password_file /etc/mosquitto/passwd
      
      

      Be sure to leave a trailing newline at the end of the file.

      allow_anonymous false will disable all non-authenticated connections, and the password_file line tells Mosquitto where to look for user and password information. Save and exit the file.

      Now we need to restart Mosquitto and test our changes.

      • sudo systemctl restart mosquitto

      Try to publish a message without a password:

      • mosquitto_pub -h localhost -t "test" -m "hello world"

      The message should be rejected:

      Output

      Connection Refused: not authorised. Error: The connection was refused.

      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:

      • mosquitto_sub -h localhost -t test -u "sammy" -P "password"

      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.

      Now publish a message with your other terminal, again using the username and password:

      • mosquitto_pub -h localhost -t "test" -m "hello world" -u "sammy" -P "password"

      The message should go through as in Step 1. We’ve successfully added password protection to Mosquitto. Unfortunately, we’re sending passwords unencrypted over the internet. We’ll fix that next by adding SSL encryption to Mosquitto.

      Step 3 — Configuring MQTT SSL

      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:

      • sudo nano /etc/mosquitto/conf.d/default.conf

      Paste in the following at the end of the file, leaving the two lines we already added:

      /etc/mosquitto/conf.d/default.conf

      . . .
      listener 1883 localhost
      
      listener 8883
      certfile /etc/letsencrypt/live/mqtt.example.com/cert.pem
      cafile /etc/letsencrypt/live/mqtt.example.com/chain.pem
      keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
      
      

      Again, be sure to leave a trailing newline at the end of the file.

      We’re adding two separate listener blocks to the config. The first, listener 1883 localhost, updates the default MQTT listener on port 1883, which is what we’ve been connecting to so far. 1883 is the standard unencrypted MQTT port. The localhost portion of the line instructs Mosquitto to only bind this port to the localhost interface, so it’s not accessible externally. External requests would have been blocked by our firewall anyway, but it’s good to be explicit.

      listener 8883 sets up an encrypted listener on port 8883. This is the standard port for MQTT + SSL, often referred to as MQTTS. The next three lines, certfile, cafile, and keyfile, all point Mosquitto to the appropriate Let’s Encrypt files to set up the encrypted connections.

      Save and exit the file, then restart Mosquitto to update the settings:

      • sudo systemctl restart mosquitto

      Update the firewall to allow connections to port 8883.

      Output

      Rule added Rule added (v6)

      Now we test again using mosquitto_pub, with a few different options for SSL:

      • mosquitto_pub -h mqtt.example.com -t test -m "hello again" -p 8883 --capath /etc/ssl/certs/ -u "sammy" -P "password"

      Note that we’re using the full hostname instead of localhost. Because our SSL certificate is issued for mqtt.example.com, if we attempt a secure connection to localhost we’ll get an error saying the hostname does not match the certificate hostname (even though they both point to the same Mosquitto server).

      --capath /etc/ssl/certs/ enables SSL for mosquitto_pub, 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 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 and mosquitto_sub will not attempt an SSL connection without this option (or the similar --cafile option), even if you’re connecting to the standard secure port of 8883.

      If all goes well with the test, we’ll see hello again show up in the other mosquitto_sub terminal. This means your server is fully set up! If you’d like to extend the MQTT protocol to work with websockets, you can follow the final step.

      Step 4 — Configuring MQTT Over Websockets (Optional)

      In order to speak MQTT using JavaScript from within web browsers, the protocol was adapted to work over standard websockets. If you don’t need this functionality, you may skip this step.

      We need to add one more listener block to our Mosquitto config:

      • sudo nano /etc/mosquitto/conf.d/default.conf

      At the end of the file, add the following:

      /etc/mosquitto/conf.d/default.conf

      . . .
      listener 8083
      protocol websockets
      certfile /etc/letsencrypt/live/mqtt.example.com/cert.pem
      cafile /etc/letsencrypt/live/mqtt.example.com/chain.pem
      keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
      
      

      Again, be sure to leave a trailing newline at the end of the file.

      This is mostly the same as the previous block, except for the port number and the protocol websockets line. There is no official standardized port for MQTT over websockets, but 8083 is the most common.

      Save and exit the file, then restart Mosquitto.

      • sudo systemctl restart mosquitto

      Now, open up port 8083 in the firewall.

      To test this functionality, we’ll use a public, browser-based MQTT client. There are a few out there, but the Eclipse Paho JavaScript Client is simple and straightforward to use. Open the Paho client in your browser. You’ll see the following:

      Paho Client Screen

      Fill out the connection information as follows:

      • Host should be the domain for your Mosquitto server, mqtt.example.com.
      • Port should be 8083.
      • ClientId can be left to the default value, js-utility-DI1m6.
      • Path can be left to the default value, /mqtt.
      • Username should be your Mosquitto username; here, we used sammy.
      • Password should be the password you chose.

      The remaining fields can be left to their default values.

      After pressing Connect, the Paho browser-based client will connect to your Mosquitto server.

      To publish a message, navigate to the Publish Message pane, fill out Topic as test, and enter any message in the Message section. Next, press Publish. The message will show up in your mosquitto_sub terminal.

      Conclusion

      We’ve now set up a secure, password-protected and SSL-secured MQTT server. This can serve as a robust and secure messaging platform for whatever projects you dream up. Some popular software and hardware that work well with the MQTT protocol include:

      • OwnTracks, an open-source geo-tracking app you can install on your phone. OwnTracks will periodically report position information to your MQTT server, which you could then store and display on a map, or create alerts and activate IoT hardware based on your location.
      • Node-RED is a browser-based graphical interface for 'wiring’ together the Internet of Things. You drag the output of one node to the input of another, and can route information through filters, between various protocols, into databases, and so on. MQTT is very well supported by Node-RED.
      • The ESP32 is an inexpensive wifi microcontroller with MQTT capabilities. You could wire one up to publish temperature data to a topic, or perhaps subscribe to a barometric pressure topic and sound a buzzer when a storm is coming!

      These are just a few popular examples from the MQTT ecosystem. There is much more hardware and software out there that speaks the protocol. If you already have a favorite hardware platform, or software language, it probably has MQTT capabilities. Have fun getting your “things” talking to each other!



      Source link

      How To Install and Secure Grafana on Ubuntu 18.04


      The author selected Dev Color to receive a donation as part of the Write for DOnations program.

      Introduction

      Grafana is an open-source data visualization and monitoring tool that integrates with complex data from sources like Prometheus, InfluxDB, Graphite, and ElasticSearch. Grafana lets you create alerts, notifications, and ad-hoc filters for your data while also making collaboration with your teammates easier through built-in sharing features.

      In this tutorial, you will install Grafana and secure it with an SSL certificate and an Nginx reverse proxy. Once you have set up Grafana, you’ll have the option to configure user authentication through GitHub, allowing you to better organize your team permissions.

      Prerequisites

      To follow this tutorial, you will need:

      Step 1 — Installing Grafana

      In this first step, you will install Grafana onto your Ubuntu 18.04 server. You can install Grafana either by downloading it directly from its official website or by going through an APT repository. Because an APT repository makes it easier to install and manage Grafana’s updates, you’ll use that method in this tutorial.

      Although Grafana is available in the official Ubuntu 18.04 packages repository, the version of Grafana there may not be the latest, so use Grafana’s official repository.

      Download the Grafana GPG key with wget, then pipe the output to apt-key. This will add the key to your APT installation’s list of trusted keys, which will allow you to download and verify the GPG-signed Grafana package.

      • wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -

      In this command, the option -q turns off the status update message for wget, and -O outputs the file that you downloaded to the terminal. These two options ensure that only the contents of the downloaded file are pipelined to apt-key.

      Next, add the Grafana repository to your APT sources:

      • sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"

      Refresh your APT cache to update your package lists:

      Next, make sure Grafana will be installed from the Grafana repository:

      The output of the previous command tells you the version of Grafana that you are about to install, and where you will retrieve the package from. Verify that the installation candidate at the top of the list will come from the official Grafana repository at https://packages.grafana.com/oss/deb.

      Output of apt-cache policy grafana

      grafana: Installed: (none) Candidate: 6.3.3 Version table: 6.3.3 500 500 https://packages.grafana.com/oss/deb stable/main amd64 Packages …

      You can now proceed with the installation:

      Once Grafana is installed, use systemctl to start the Grafana server:

      • sudo systemctl start grafana-server

      Next, verify that Grafana is running by checking the service’s status:

      • sudo systemctl status grafana-server

      You will receive output similar to this:

      Output of grafana-server status

      ● grafana-server.service - Grafana instance Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; disabled; vendor preset: enabled) Active: active (running) since Tue 2019-08-13 08:22:30 UTC; 11s ago Docs: http://docs.grafana.org Main PID: 13630 (grafana-server) Tasks: 7 (limit: 1152) …

      This output contains information about Grafana’s process, including its status, Main Process Identifier (PID), and more. active (running) shows that the process is running correctly.

      Lastly, enable the service to automatically start Grafana on boot:

      • sudo systemctl enable grafana-server

      You will receive the following output:

      Output of systemctl enable grafana-server

      Synchronizing state of grafana-server.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable grafana-server Created symlink /etc/systemd/system/multi-user.target.wants/grafana-server.service → /usr/lib/systemd/system/grafana-server.service.

      This confirms that systemd has created the necessary symbolic links to autostart Grafana.

      Grafana is now installed and ready for use. Next, you wil secure your connection to Grafana with a reverse proxy and SSL certificate.

      Step 2 — Setting Up the Reverse Proxy

      Using an SSL certificate will ensure that your data is secure by encrypting the connection to and from Grafana. But, to make use of this connection, you’ll first need to reconfigure Nginx as a reverse proxy for Grafana.

      Open the Nginx configuration file you created when you set up the Nginx server block with Let’s Encrypt in the Prerequisites. You can use any text editor, but for this tutorial we’ll use nano:

      • sudo nano /etc/nginx/sites-available/your_domain

      Locate the following block:

      /etc/nginx/sites-available/your_domain

      …
          location / {
              try_files $uri $uri/ =404;
          }
      …
      

      Because you already configured Nginx to communicate over SSL and because all web traffic to your server already passes through Nginx, you just need to tell Nginx to forward all requests to Grafana, which runs on port 3000 by default.

      Delete the existing try_files line in this location block and replace it with the following proxy_pass option.

      /etc/nginx/sites-available/your_domain

      …
          location / {
              proxy_pass http://localhost:3000;
          }
      …
      

      This will map the proxy to the appropriate port. Once you’re done, save and close the file by pressing CTRL+X, followed by Y and then ENTER if you’re using nano.

      Now, test the new settings to make sure everything is configured correctly:

      You will receive the following output:

      Output

      nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      Finally, activate the changes by reloading Nginx:

      • sudo systemctl reload nginx

      You can now access the default Grafana login screen by pointing your web browser to https://your_domain. If you’re unable to reach Grafana, verify that your firewall is set to allow traffic on port 443 and then re-trace the previous instructions.

      With the connection to Grafana encrypted, you can now implement additional security measures, starting with changing Grafana’s default administrative credentials.

      Step 3 — Updating Credentials

      Because every Grafana installation uses the same administrative credentials by default, it is best practice to change your login information as soon as possible. In this step, you’ll update the credentials to improve security.

      Start by navigating to https://your_domain from your web browser. This will bring up the default login screen where you’ll see the Grafana logo, a form asking you to enter an email or username and password, a Log in button, and a Forgot your password? link.

      Grafana Login

      Enter admin into both the User and Password fields and then click on the Log in button.

      On the next screen, you’ll be asked to make your account more secure by changing the default password:

      Change Password

      Enter the password you’d like to start using into the New password and Confirm new password fields.

      From here, you can click Save to save the new information or press Skip to skip this step. If you skip, you will be prompted to change the password next time you login.

      In order to increase the security of your Grafana setup, click Save. You’ll return to the Home Dashboard page:

      Home Dashboard

      You’ve now secured your account by changing the default credentials. Next, you will make changes to your Grafana configuration so that nobody can create a new Grafana account without your permission.

      Step 4 — Disabling Grafana Registrations and Anonymous Access

      Grafana provides options that allow visitors to create user accounts for themselves and preview dashboards without registering. When Grafana isn’t accessible via the internet or when it’s working with publicly available data like service statuses, you may want to allow these features. However, when using Grafana online to work with sensitive data, anonymous access could be a security problem. To fix this problem, make some changes to your Grafana configuration.

      Start by opening Grafana’s main configuration file for editing:

      • sudo nano /etc/grafana/grafana.ini

      Locate the following allow_sign_up directive under the [users] heading:

      /etc/grafana/grafana.ini

      …
      [users]
      # disable user signup / registration
      ;allow_sign_up = true
      …
      

      Enabling this directive with true adds a Sign Up button to the login screen, allowing users to register themselves and access Grafana.

      Disabling this directive with false removes the Sign Up button and strengthens Grafana’s security and privacy.

      Uncomment this directive by removing the ; at the beginning of the line and then setting the option to false:

      /etc/grafana/grafana.ini

      …
      [users]
      # disable user signup / registration
      allow_sign_up = false

      Next, locate the following enabled directive under the [auth.anonymous] heading:

      /etc/grafana/grafana.ini

      …
      [auth.anonymous]
      # enable anonymous access
      ;enabled = false
      …
      

      Setting enabled to true gives non-registered users access to your dashboards; setting this option to false limits dashboard access to registered users only.

      Uncomment this directive by removing the ; at the beginning of the line and then setting the option to false.

      /etc/grafana/grafana.ini

      …
      [auth.anonymous]
      enabled = false

      Save the file and exit your text editor.

      To activate the changes, restart Grafana:

      • sudo systemctl restart grafana-server

      Verify that everything is working by checking Grafana’s service status:

      • sudo systemctl status grafana-server

      Like before, the output will report that Grafana is active (running).

      Now, point your web browser to https://your_domain. To return to the Sign Up screen, bring your cursor to your avatar in the lower left of the screen and click on the Sign out option that appears.

      Once you have signed out, verify that there is no Sign Up button and that you can’t sign in without entering login credentials.

      At this point, Grafana is fully configured and ready for use. Next, you can simplify the login process for your organization by authenticating through GitHub.

      (Optional) Step 5 — Setting Up a GitHub OAuth App

      For an alternative approach to signing in, you can configure Grafana to authenticate through GitHub, which provides login access to all members of authorized GitHub organizations. This can be particularly useful when you want to allow multiple developers to collaborate and access metrics without having to create Grafana-specific credentials.

      Start by logging into a GitHub account associated with your organization and then navigate to your GitHub profile page at https://github.com/settings/profile.

      Click on your organization’s name under Organization settings in the navigation menu on the left-hand side of the screen.

      GitHub Organization settings

      On the next screen, you’ll see your Organization profile where you can change settings like your Organization display name, organization Email, and organization URL.

      Because Grafana uses OAuth — an open standard for granting remote third parties access to local resources — to authenticate users through GitHub, you’ll need to create a new OAuth application within GitHub.

      Click the OAuth Apps link under Developer settings on the lower left-hand side of the screen.

      If you don’t already have any OAuth applications associated with your organization on GitHub, you’ll be told there are No Organization Owned Applications. Otherwise, you’ll see a list of the OAuth applications already connected to your account.

      Click the Register an application button to continue.

      On the next screen, fill in the following details about your Grafana installation:

      • Application name - This helps you distinguish your different OAuth applications from one another.
      • Homepage URL - This tells GitHub where to find Grafana. Type https://your_domain into this field, replacing your_domain with your domain.
      • Application Description - This provides a description of your OAuth application’s purpose.
      • Application callback URL - This is the address where users will be sent once successfully authenticated. For Grafana, this field must be set to https://your_domain/login/github.

      Keep in mind that Grafana users logging in through GitHub will see the values you entered in the first three preceding fields, so be sure to enter something meaningful and appropriate.

      When completed, the form will look something like:

      GitHub Register OAuth Application

      Click the green, Register application button.

      You will now be redirected to a page containing the Client ID and Client Secret associated with your new OAuth application. Make note of both values, because you will need to add them to Grafana’s main configuration file to complete the setup.

      Warning: Make sure to keep your Client ID and Client Secret in a secure and non-public location, because they could be used as the basis of an attack.

      With your GitHub OAuth application created, you’re now ready to reconfigure Grafana to use GitHub for authentication.

      (Optional) Step 6 — Configuring Grafana as a GitHub OAuth App

      To complete GitHub authentication for your Grafana setup, you will now make some changes to your Grafana configuration files.

      To begin, open the main Grafana configuration file.

      • sudo nano /etc/grafana/grafana.ini

      Locate the [auth.github] heading, and uncomment this section by removing the ; at the beginning of every line except ;team_ids=, which will not be changed in this tutorial.

      Next, configure Grafana to use GitHub with your OAuth application’s client_id and client_secret values.

      • Set enabled and allow_sign_up to true. This will enable GitHub Authentication and permit members of the allowed organization to create accounts themselves. Note that this setting is different than the allow_sign_up property under [users] that you changed in Step 4.
      • Set client_id and client_secret to the values you got while creating your GitHub OAuth application.
      • Set allowed_organizations to the name of your organization to ensure that only members of your organization can sign up and log into Grafana.

      The complete configuration will look like:

      /etc/grafana/grafana.ini

      …
      [auth.github]
      enabled = true
      allow_sign_up = true
      client_id = your_client_id_from_github
      client_secret = your_client_secret_from_github
      scopes = user:email,read:org
      auth_url = https://github.com/login/oauth/authorize
      token_url = https://github.com/login/oauth/access_token
      api_url = https://api.github.com/user
      ;team_ids =
      allowed_organizations = your_organization_name

      You’ve now told Grafana everything it needs to know about GitHub. To complete the setup, you’ll need to enable redirects behind a reverse proxy. This is done by setting a root_url value under the [server] heading.

      /etc/grafana/grafana.ini

      …
      [server]
      root_url = https://your_domain

      Save your configuration and close the file.

      Then, restart Grafana to activate the changes:

      • sudo systemctl restart grafana-server

      Lastly, verify that the service is up and running.

      • sudo systemctl status grafana-server

      The output will indicate that the service is active (running).

      Now, test your new authentication system by navigating to https://your_domain. If you are already logged into Grafana, hover your mouse over the avatar log in the lower left-hand corner of the screen, and click on Sign out in the secondary menu that appears next to your name.

      On the login page, you’ll see a new section under the original Log in button that includes a Sign in with GitHub button with the GitHub logo.

      Grafana Login page with GitHub

      Click on the Sign in with GitHub button to be redirected to GitHub, where you’ll sign into your GitHub account and confirm your intention to Authorize Grafana.

      Click the green, Authorize your_github_organization button.

      Note: Make sure your GitHub account is a member of your approved organization and your Grafana email address matches your GitHub email address. If you try to authenticate with a GitHub account that isn’t a member of your approved organization, you’ll get a Login Failed message telling you, User not a member of one of the required organizations.

      You will now be logged in with your existing Grafana account. If a Grafana account doesn’t already exist for the user you logged in as, Grafana will create a new user account with Viewer permissions, ensuring that new users can only use existing dashboards.

      To change the default permissions for new users, open the main Grafana configuration file for editing.

      • sudo nano /etc/grafana/grafana.ini

      Locate the auto_assign_org_role directive under the [users] heading, and uncomment the setting by removing the ; at the beginning of the line.

      Set the directive to one of the following values:

      • Viewer — can only use existing dashboards
      • Editor — can change use, modify, and add dashboards
      • Admin — has permission to do everything

      This tutorial will set the auto-assign to Viewer:

      /etc/grafana/grafana.ini

      …
      [users]
      …
      auto_assign_org_role = Viewer

      Once you’ve saved your changes, close the file and restart Grafana:

      • sudo systemctl restart grafana-server

      Check the service’s status:

      • sudo systemctl status grafana-server

      Like before, the status will read active (running).

      At this point, you have fully configured Grafana to allow members of your GitHub organization to register and use your Grafana installation.

      Conclusion

      In this tutorial you installed, configured, and secured Grafana, and you also learned how to permit members of your organization to authenticate through GitHub.

      To extend your current Grafana installation, see the list of official and community-built dashboards. To learn more about using Grafana in general, see the official Grafana documentation, or check out our other monitoring tutorials.



      Source link